[webkit-dev] Translucent (i)frames support

Thu Jul 17 11:17:12 PDT 2008

The bug on Mac at least is just that NSScrollViews blit when  
scrolling, and they know nothing about transparency layers.   Our  
solution to similar problems has been to just disable blitting in  
these cases and do slow repainting when scrolling happens.  Because  
there is *no cache* of transparency layer contents, we are unable to  
do a blit directly within the transparency layer itself, so a slow  
redraw is the only option.  Moving to a model where we cache bitmaps  
for transparency layers is possible but potentially wasteful memory- 
wise given the way CSS opacity is designed.

dave

On Jul 17, 2008, at 9:36 AM, Artem Ananiev wrote:

> Hi, webkit developers,
>
> I have recently faced a problem with support for translucent (i)frames
> in our (java) port, and tried to find how other ports (gtk, win, mac)
> deal with the same issue. The test is short (launch the test and try  
> to
> scroll inner frames):
>
> <html>
> <body>
>
> <div style="opacity:0.5;position:absolute;left:150;top:150">
>   <iframe src="http://java.sun.com/javase/6/docs/api" width="600"
> height="450"></iframe>
> </div>
>
> <div style="opacity:0.2;position:absolute;left:250;top:250">
>   <iframe src="http://java.sun.com/javase/6/docs/api" width="600"
> height="450"></iframe>
> </div>
>
> </body>
> </html>
>
> I was very surprised when found no webkit ports displayed the page
> correctly! I tried Safari 3.1 on Mac and Win and GTK Launcher on Linux
> (haven't looked at Safari 4.0, though). The only browser which  
> 'passed'
> the test was Firefox: all the frames were displayed correctly and
> scrolled smoothly.
>
> It seems that both mac/win and gtk ports use some caches for rendered
> pages, however some bugs exist in the implementations. In Java port we
> have two different approaches for rendering: one is fast, but without
> any support of translucent (i)frames, another is correct (even with  
> the
> test above), but slow. The second one is a kind of experimental, and
> what I want to do is to speed it up (by using some rendering cache)  
> and
> make it default.
>
> The next two days I spent trying to implement the correct rendering
> cache. The idea is simple: render all the frames separately from each
> other to different offscreen images, and composite them to get a final
> image on the screen. However, I failed with this task :(
>
> The first part is simple: to render the frame contents I call
> Frame::paint(gc, rect) and skip all subsequent Widget::paint(gc, rect)
> calls. That's fine. The second part - compositing - is somewhat I
> couldn't implement. The problem is there is no way (or I don't know  
> this
> way) for a given Frame to render all its child frames without  
> rendering
> the frame itself. In other words, I have to render some part of the
> frame twice: first, all the dirty regions into the cache, and second,
> all the frame to get children painted correctly.
>
> Any ideas?
>
> Thanks,
>
> Artem
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev