- Dillo-dev - lists.mailman3.com

image background colors

by Johannes.Hofmann＠gmx.de

On Sat, Apr 24, 2010 at 07:43:38PM +0000, corvid wrote: > Johannes wrote: > > On Wed, Apr 21, 2010 at 10:28:46AM +0200, Johannes Hofmann wrote: > > > On Wed, Apr 21, 2010 at 05:01:11AM +0000, corvid wrote: > > > > Is this anywhere near correct? > > > > > > It is definately better than what we have now, but somehow this > > > image background handling is a bit of a hack all together. > > > Basically the Image Widget should get the background color via > > > Widget::getBgColor() at drawing time. > > > That would avoid any special handling in html.cc and would allow to > > > modify the background color by setting a different style. > > > However I can't see any easy way to achive this atm. > > > > It seems that dw/imgbuf.hh supports RGBA images already. We > > probabely want to use them instead of just RGB with merged in > > background color. Otherwise we will have problems as in the > > following example (due to the shared image buffer): > > I played with this some time ago > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-May/004265.html > and had some difficulties. > > I'll have to see whether I still have that code around somewhere... That would be cool. I'd really like to remove the image background handling from src/* and use RGBA image buffers instead.

April 24, 2010

image background colors

by corvid＠lavabit.com

Johannes wrote: > On Wed, Apr 21, 2010 at 10:28:46AM +0200, Johannes Hofmann wrote: > > On Wed, Apr 21, 2010 at 05:01:11AM +0000, corvid wrote: > > > Is this anywhere near correct? > > > > It is definately better than what we have now, but somehow this > > image background handling is a bit of a hack all together. > > Basically the Image Widget should get the background color via > > Widget::getBgColor() at drawing time. > > That would avoid any special handling in html.cc and would allow to > > modify the background color by setting a different style. > > However I can't see any easy way to achive this atm. > > It seems that dw/imgbuf.hh supports RGBA images already. We > probabely want to use them instead of just RGB with merged in > background color. Otherwise we will have problems as in the > following example (due to the shared image buffer): I played with this some time ago http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-May/004265.html and had some difficulties. I'll have to see whether I still have that code around somewhere...

April 24, 2010

image background colors

by Johannes.Hofmann＠gmx.de

On Wed, Apr 21, 2010 at 10:28:46AM +0200, Johannes Hofmann wrote: > On Wed, Apr 21, 2010 at 05:01:11AM +0000, corvid wrote: > > Is this anywhere near correct? > > It is definately better than what we have now, but somehow this > image background handling is a bit of a hack all together. > Basically the Image Widget should get the background color via > Widget::getBgColor() at drawing time. > That would avoid any special handling in html.cc and would allow to > modify the background color by setting a different style. > However I can't see any easy way to achive this atm. It seems that dw/imgbuf.hh supports RGBA images already. We probabely want to use them instead of just RGB with merged in background color. Otherwise we will have problems as in the following example (due to the shared image buffer): <div style="background-color: green"> <img src="http://www.libpng.org/pub/png/img_png/stefan_pal_rgba.png" /> </div> <div style="background-color: red"> <img src="http://www.libpng.org/pub/png/img_png/stefan_pal_rgba.png" /> </div> Cheers, Johannes

April 24, 2010

style.css font-family misses redraw

by corvid＠lavabit.com

Johannes wrote: > On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > > If you specify a font-family in ~/.dillo/style.css, such as: > > > > * { font-family:sans-serif } > > > > And then visit a page like: > > > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > > > ... it will produce "ghost" lines from the previous rendering before > > the css was applied. Moving the window, or doing anything else that > > forces a redraw, cleans it up. (Let me know if you don't see this and I > > can provide a screenshot.) > > Hm, the page does not seem to contain any CSS, so it renders with > just the user agent style and the user style (~/.dillo/style.css) > even the first time it draws. Maybe it's because of the images that > change the layout once loaded? > Can you reproduce the issue with load_images=NO? > > I've alse seen "ghost" lines on some pages, but could never find > the real reason. I only remeber that it depended on timing somehow. I didn't see a problem, either. I'm usually using buffered_drawing=2, if that's relevant, and all I ever see is that sometimes when I load an image that enlarges a table, it...leaves a line for the old bottoms of neighboring cells, or something like that. I don't remember exactly for sure what happens. It's rare, and I ignore it in any case because I would prefer not to dig into the table code...

April 24, 2010

style.css font-family misses redraw

by Johannes.Hofmann＠gmx.de

On Fri, Apr 23, 2010 at 10:55:23AM -0400, Dennis Nezic wrote: > If you specify a font-family in ~/.dillo/style.css, such as: > > * { font-family:sans-serif } > > And then visit a page like: > > http://www.linuxfromscratch.org/lfs/downloads/6.6/ > > ... it will produce "ghost" lines from the previous rendering before > the css was applied. Moving the window, or doing anything else that > forces a redraw, cleans it up. (Let me know if you don't see this and I > can provide a screenshot.) Hm, the page does not seem to contain any CSS, so it renders with just the user agent style and the user style (~/.dillo/style.css) even the first time it draws. Maybe it's because of the images that change the layout once loaded? Can you reproduce the issue with load_images=NO? I've alse seen "ghost" lines on some pages, but could never find the real reason. I only remeber that it depended on timing somehow. Cheers, Johannes

April 23, 2010

style.css font-family misses redraw

by dennisn＠dennisn.dyndns.org

If you specify a font-family in ~/.dillo/style.css, such as: * { font-family:sans-serif } And then visit a page like: http://www.linuxfromscratch.org/lfs/downloads/6.6/ ... it will produce "ghost" lines from the previous rendering before the css was applied. Moving the window, or doing anything else that forces a redraw, cleans it up. (Let me know if you don't see this and I can provide a screenshot.)

April 23, 2010

zero-delay refresh, but no URL

by jcid＠dillo.org

On Fri, Apr 23, 2010 at 01:19:28AM +0000, corvid wrote: > Jorge wrote: > > > So perhaps the nav redirection stuff should use bw->redirect_level. > > > > This looks like a good idea. > > If you want to make a patch go ahead, I'll look at the expect url > > issue with zero-delay refresh now. > > I see that, in Cache_process_queue(), redirect_level is zeroed if > CA_Redirect isn't set. I wonder whether, since this is http-equiv, > it should reach into cache in a way that's similar to Content-Type > and let us rip out the nav redirection code. This may be a sleeping dragon. It could look cleaner if handled in cache, but there's a need to sync the redirecting-URL not to end in the history stack, while at the same time letting the resource finish loading and to assert repush works OK (part of this is achieved by using a timeout in nav). Maybe it can be done easily, I don't know yet. Although I remember very well that "charset" given by HTML's META was a royal PITA to handle! (chicken/egg problem). ATM we're handling zero-delay redirection for root URLs only. I see little use for generalizing it to child resources. I see clear gain in the case of HTTP redirection. My point is: it could take a significative effort that would be better spent on something more urgent/strategic for the project. -- Cheers Jorge.-

April 23, 2010

zero-delay refresh, but no URL

by corvid＠lavabit.com

Jorge wrote: > > So perhaps the nav redirection stuff should use bw->redirect_level. > > This looks like a good idea. > If you want to make a patch go ahead, I'll look at the expect url > issue with zero-delay refresh now. I see that, in Cache_process_queue(), redirect_level is zeroed if CA_Redirect isn't set. I wonder whether, since this is http-equiv, it should reach into cache in a way that's similar to Content-Type and let us rip out the nav redirection code.

April 23, 2010

zero-delay refresh, but no URL

by corvid＠lavabit.com

Jorge wrote: > On Thu, Apr 22, 2010 at 05:53:00AM +0000, corvid wrote: > > http://www.algo-prog.info/ocmc/ > > contains > > <meta http-equiv="refresh" content="0;web/" /> > > > > For refresh, we assume there will be an '=' from "URL=". > > Unfortunately there's no standard for the content string in a META > refresh. The example by W3C uses "URL=" so it looks OK to expect it. I was tempted to complain in my previous mail about how it was underspecified :) Some sufficiently old html specs didn't show the URL=, incidentally http://www.w3.org/TR/1998/REC-html40-19980424/struct/global.html#h-7.4.4

April 22, 2010

zero-delay refresh, but no URL

by jcid＠dillo.org

On Thu, Apr 22, 2010 at 05:53:00AM +0000, corvid wrote: > http://www.algo-prog.info/ocmc/ > contains > <meta http-equiv="refresh" content="0;web/" /> > > For refresh, we assume there will be an '=' from "URL=". Unfortunately there's no standard for the content string in a META refresh. The example by W3C uses "URL=" so it looks OK to expect it. > Since there isn't one, we refresh the same URL over and over and over... > > We could refuse to follow a zero-delay refresh without a new URL, > but I seem to recall back in the never-follow days that sometimes > a page _wanted_ to be immediately refreshed once, after which it > would provide the contents (I always wondered why). > > So perhaps the nav redirection stuff should use bw->redirect_level. This looks like a good idea. If you want to make a patch go ahead, I'll look at the expect url issue with zero-delay refresh now. -- Cheers Jorge.-

April 22, 2010