[webkit-dev] Translucent (i)frames support

David Hyatt hyatt at apple.com
Mon Jul 21 13:32:23 PDT 2008


On Jul 21, 2008, at 3:24 AM, Artem Ananiev wrote:

>
> 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?

ScrollView has a (horribly named) method called:

void setStaticBackground(bool);

"static background" used to mean "don't blit when you scroll because  
the Web page has a fixed background that doesn't move when you  
scroll."  As we found more situations where blitting was impossible we  
reused that method, so now it really just means "don't blit when you  
scroll."

Cross-platform code calls this method.  Look at FrameView.cpp, which  
has a "useSlowRepaints" boolean.   It passes that boolean to  
setStaticBackground.

Your port needs to honor this method, using blitting only if the  
static background bool is false.  As of right now, the notion of  
whether or not you can blit is completely cross-platform, so your port  
(in order to avoid misrendering) needs to obey this boolean in order  
to render pages properly.

> 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.
>

Yes, the performance when you can't blit is significantly worse.

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

Right now a port has exactly one option.  The decision of when to blit  
or not blit is made in cross-platform code.  To do anything else would  
require changes in the cross-platform code.

dave
(hyatt at apple.com)



More information about the webkit-dev mailing list