patch: drawing image map areas
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. If I try http://www.sbrady.com/hotsource/html/imgmaps.html because it has bigger rectangles, when I scroll line by line, I get lines in my rectangle corresponding to the edge of the view. No problem with circles or polygons. All I'm doing is calling the fltk shape-drawing code through fltkviewbase, so I'd expect them all to work or break in the same way. I will probably change FltkViewBase::drawArc() so that (x,y) is the center like one would expect. That tricked me at first, and I might have been the one who wrote that code in the first place. I might make an additional FltkViewBase::drawPolygon() that accepts the SimpleVector of points and then calls addvertex() a lot rather than one addvertices() call. Slower, but they're just image maps, and the pointArray in Polygon::draw() here is too complicated (I had to look it up to get it quite right).
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.
Nice!
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.
Not sure about this one yet.
If I try http://www.sbrady.com/hotsource/html/imgmaps.html because it has bigger rectangles, when I scroll line by line, I get lines in my rectangle corresponding to the edge of the view. No problem with circles or polygons.
Ha, that seems to be a problem introduced by my attempt to fix coordinate overflows with huge borders. For borders we always use filled rectangles and for those the problem is invisible. I will fix that somehow. Cheers, Johannes
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.
If I try http://www.sbrady.com/hotsource/html/imgmaps.html because it has bigger rectangles, when I scroll line by line, I get lines in my rectangle corresponding to the edge of the view.
This should be fixed now. The only place where we currently use non-filled rectangles is bullet.cc and indeed I could reproduce the issue with nested <ul>s and drag scrolling. Cheers, Johannes PS: Feel free to commit your patch, we can resolve remaining issues in-tree.
Johannes wrote:
This should be fixed now. The only place where we currently use non-filled rectangles is bullet.cc and indeed I could reproduce the issue with nested <ul>s and drag scrolling.
Thanks.
PS: Feel free to commit your patch, we can resolve remaining issues in-tree.
Done.
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. Cheers, Johannes PS: The new viewsource dpi was super handy browsing the sources of the example pages!
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.
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): diff -r 7aca003dbfca dw/image.hh --- a/dw/image.hh Sun Mar 14 19:09:24 2010 +0000 +++ b/dw/image.hh Tue Mar 16 11:39:25 2010 +0100 @@ -159,6 +159,7 @@ void setIsMap (); void setUseMap (ImageMapsList *list, Object *key); + void forceMapRedraw () { if (mapKey && ! buffer) queueDraw (); }; }; } // namespace dw diff -r 7aca003dbfca src/html.cc --- a/src/html.cc Sun Mar 14 19:09:24 2010 +0000 +++ b/src/html.cc Tue Mar 16 11:39:25 2010 +0100 @@ -2199,6 +2199,11 @@ */ static void Html_tag_close_map(DilloHtml *html, int TagIdx) { + for (int i = 0; i < html->images->size(); i++) { + dw::Image *img = (dw::Image *) html->images->get(i)->image->dw; + + img->forceMapRedraw(); + } html->InFlags &= ~IN_MAP; }
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):
Yeah, I think I'd be willing to commit that with comments. It occurs to me that programmers...we have the ideas of pointing out bugs, workarounds, explaining complexities -- but I don't know whether I've seen a project keeping track of "this is something that you can consider taking out again if it should cause serious headaches someday". Somewhat related, but perhaps very difficult to see at the time is "This is done in this particular way to fit with what we are given by [something, e.g., gtk], and needn't be kept in this form if what we interface with changes."
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.
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: diff -r 5fafc795ebbd dw/image.hh --- a/dw/image.hh Sat Mar 20 01:55:00 2010 +0000 +++ b/dw/image.hh Sat Mar 20 11:26:02 2010 +0100 @@ -159,6 +159,7 @@ void setIsMap (); void setUseMap (ImageMapsList *list, Object *key); + void forceMapRedraw () { if (mapKey && ! buffer) queueDraw (); }; }; } // namespace dw diff -r 5fafc795ebbd src/html.cc --- a/src/html.cc Sat Mar 20 01:55:00 2010 +0000 +++ b/src/html.cc Sat Mar 20 11:26:02 2010 +0100 @@ -2199,6 +2199,12 @@ */ static void Html_tag_close_map(DilloHtml *html, int TagIdx) { + for (int i = 0; i < html->images->size(); i++) { + DilloImage *img = html->images->get(i)->image; + + if (img) + ((dw::Image*) img->dw)->forceMapRedraw(); + } html->InFlags &= ~IN_MAP; } BTW: I found another nice image map example: http://html.cita.uiuc.edu/text/map/map-example.php Cheers, Johannes
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...
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.
participants (2)
-
corvid＠lavabit.com -
Johannes.Hofmann＠gmx.de