[webkit-dev] Translucent (i)frames support

Mon Jul 21 01:24:19 PDT 2008

David Hyatt wrote:
> 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.

Is there any information available about performance of 'slow redraw' 
approach? I can't check the patch you have provided (just have no 
appropriate desktop to build Mac port), but I see the significant 
regression for Java port when Swing's blitting is turned off. That's why 
I have posted my question here.

The general idea of my post is the following. With the current WebKit 
code, any port has three options:

1. Always use 'slow redraw' approach. Page rendering is always correct, 
but always slow.

2. Use 'slow redraw' for translucent (i)frames only. This requires some 
knowledge of the DOM tree (at least, 'opacity' attribute), which may not 
be available (yes, I can call some WebCore/dom/ or WebCore/rendering/ 
classes from platform's code, but I suspect this is not a good way).

3. Use some kind of caching or blitting available in platform's 
libraries (like NSScrollView on Mac or JScrollPane in Java). Page 
rendering may or may not be correct - see the test - while performance 
is good.

Unfortunately, I haven't found a way to implement option 3, so both 
performance and rendering are fine. For Java platform, it is enough to 
have a method like 'Frame::paint(gc, rect)' which doesn't paint the 
frame itself, but only its children. Still, other ports (gtk, qt, etc._ 
may not benefit from it... It would be fine to hear their ideas too.

Thanks,

Artem

> 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
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev