156933 - draw filled rectangles instead of one-color-images

Status: VERIFIED WONTFIX

(Core :: Printing: Output, enhancement, P5)

Description

[Peter Niemayer]

It is quite common for HTML authors to use images (<IMG ...> tags) - mostly tiny
or 1x1 pixel size ones - to fill rectangles with a color, most often table cells
or such, but they even draw lines with that.

For a PDF writer module I implemented an extremely simple optimization that has
quite a nice effect: Before drawing an image, I simply check whether all pixels
of the image have the same color, and if so, I substitute the image by a solid
filled rectangle of the same size. This saves tremendous amounts of space,
printing- and rendering-performance for some web-pages.

Of course, such an optimization could be even more efficiently done at a
"higher" level, when reading the image for example. Then not only one output
device but all would benefit.

Sorry I didn't find a better category for this proposal than "printing"... maybe
someone else knows who could add this few-lines-big-effect optimization :-)


Reproducible: Always
Steps to Reproduce:
Just have a look at the source of popular web-pages such as
http://www.netscape.com/

Comment 1

[rods (gone)]

sounds like an issue for Don

Comment 2

[dcone (gone)]

This was a workaround.. right.  6.0 you can now specify the color of a table
cell.. so there would be no need for this correct?  

Comment 3

[Peter Niemayer]

Well, as there are vast amounts of existing web-pages with dozens to hundreds of
such images, and it is not forseeable when everyone will use more appropriate
methods than those one-color-images, and since the optimization only needs very
few lines of code, I'd say it's quite worthwhile.

Comment 4

[dcone (gone)]

very low priority.

Comment 5

[Roland Mainz]

dcone wrote:
> very low priority.

Why ?
Drawing an image as very expensive compared to a simple FillRect command. We
should get some performance improvment on some platforms (like X11 or
VMware+Win32) when we implement this.

Comment 6

[dcone (gone)]

1.)  Because with Netscape 6.0 and Explorer.. the web page designers have a way
to put in the correct HTML to take care of this problem.  Table cells now have
backgrounds.. thats what this fixes when that was not an option.
2.)  It can be expensive finding out on every draw or at some point if the
bitmap has all the same colors or is transparent.. since images can be dynamic
or change we would have to have some support for keeping track.  I think its
wrong to look for shortcuts just so you can get a backwards compatibility for
something that has been fixed in the specifications and later applications. 
This fix also complicates maintance of the current code.. putting in an
optimization (more on that later) so we support what web page designers did as a
hack.  We did our part in doing thing correctly.. it is now there turn.
3.)  On some platforms this may not be an optimization.. On windows.. drawing a
rectangle is the same as a blit.. so you don't save any speed.. actually.  On
windows drawing the rectangles is one of the higher costs.  This could be true
on other platforms also.. because rectangle fills do pattern fills and those are
handled alot of times with pattern blitting code.  I know this for a fact on
windows, and is a high probabilty on the Mac.

I would really like to close this bug.. because I don't agree with this
optimization at all.  I think we did what the HTML designers needed to give them
a speed increase (use a background on a table cell).  I have never been in favor
of supporting a hack.. because it means more maintance nightmares for us in the
long run.  

Comment 7

[Peter Niemayer]

> ...the web page designers have a way to put in the correct HTML to take care
of this problem...

I'd immediately agree with that argument if you could convince at least the
www.netscape.com designers not to use the bad old hack anymore...

BTW: As you mentioned transparency: I also noticed that many images are reported
to have a transparency map by the nsIImage interface, while closer inspection
reveals that transparency map is often completely opaque. So for our PDF device
context I implemented another detection to remove such unneccessary transparency
maps. Let me guess: Blitting partly transparent bitmaps under windows is still
not supposed to be more expensive than intransparent ones? :-)

Comment 8

[dcone (gone)]

Marking this as won't fix.  I would suggest that if you want this to go
forward.. post a bug that the Netscape page should be re-designed to use the
right HTML. 

Comment 9

[sujay]

verified.