On Sat, Mar 20, 2010 at 03:55:40PM +0000, corvid wrote:
Johannes wrote:
On Sat, Mar 20, 2010 at 02:49:58AM +0000, corvid wrote:
Johannes wrote:
On Mon, Mar 15, 2010 at 10:54:32PM +0000, corvid wrote:
Johannes wrote:
On Sat, Mar 06, 2010 at 12:46:57AM +0000, corvid wrote: > This draws the shapes in image maps, which is quite nice when not > loading images. > > > There are two redrawing problems: > > If I try http://earthquake.usgs.gov/earthquakes/recenteqsww/ > a little bit of the map is visible at the bottom of the viewport > initially (geometry 850x630). The rectangles are visible, but not > the polygons. If I page down or switch to another desktop and back, > all is well.
I think I found the cause of the second drawing issue:
It's not specific to polygons, it's just that in the example page the polygons are defined last. The problem is that the shapes are defined after the image, so HTML code way below the definition of the actual image can now influence how the image should be drawn. If by accident the image get's drawn before the image map has been parsed, the shapes are not visible.
We need to issue a queueDraw() for each affected image when adding a shape to an image map. The problem is that I think there currently is no reference from image maps to images using the map.
Hmm, I sort of wonder whether I should take it back out. It's a somewhat frivolous feature that only I would see, and I am reluctant to increase the General Entanglement of Things in such a case.
You are right that we should not add too much complexity for this special case, but we could do it in a brute force way like this (plus adding some big comments explaining the issue):
Gave it a try and crashed after a bit. When we try to load an image, the DilloImage* in the html list is set to NULL because we have given it to the web.
Ah ok, but we can simply add a check for that case:
Then we wouldn't have shapes drawn when dillo has requested the image, but maybe that's all right...
Yes, there is this gap, but I'd say it's ok.