Closed Bug 166932 Opened 19 years ago Closed 14 years ago

Optimize view opacity

Categories

(Camino Graveyard :: Page Layout, defect, P2)

PowerPC
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED
Camino2.0

People

(Reporter: sfraser_bugs, Unassigned)

References

Details

(Keywords: perf)

Attachments

(4 obsolete files)

Why aren't the following views opaque in Chimera?

CHBrowserView
BrowserWrapper

Also, is there a way we can tell if ChildViews can be opaque?

Simply making the CHBrowserView and BrowserWarpper opaque cause lots of
scrolling/typing issues, but I'd like to understand why.
Summary: OpOptimize view opacity → Optimize view opacity
Target Milestone: --- → Chimera1.2
I think this might be a bit of a perf win. Every time we redraw we content, we draw the window 
background in the invalidated area before it gets convered by content. This shows up as time spent in 
[BrowserTabView drawRect:].

Making [BrowserWrapper isOpaque] return YES causes redraw issues, oddly.

If we make the root nsChildView opaque, we also get redraw issues, but these can be solved with a call 
to QDFlushPortBuffer() after the redraw. Something odd is happening here.
Keywords: perf
Attached patch Hacky patch (obsolete) — Splinter Review
This patch attempts to make the root nsChildView opaque, and then fix the
drawing issues that result: I call QDFlushPortBuffer() after a redraw. This
make stuff appear on screen, but causes a lot of flickering.
You'd think that QDAddRectToDirtyRegion() would work, but it doesn't. This is
more NSQuickdrawView skankyness, I'm sure.
Is this still an issue? smfr?
Attached patch Another patch, mostly working (obsolete) — Splinter Review
This patch flushes the port in drawRect:, which works better. The only issue I
see here is some garbage pixels at the edges of views while doing live resize.
Assignee: pinkerton → sfraser_bugs
Attachment #142508 - Attachment is obsolete: true
Status: NEW → ASSIGNED
I temporarily checked that patch in to see if it affected pageload performance.
The impact was negligible.

It does, however, make a big difference in some redraw issues like bug 272954
and bug 280982.
Attached patch Make CHBrowserView opaque (obsolete) — Splinter Review
We can stop view updates from propagating above our CHBrowserView, by making it
opaque (as this patch does). It just draws white.
Comment on attachment 179025 [details] [diff] [review]
Make CHBrowserView opaque

I checked this patch in.
Attachment #179025 - Attachment is obsolete: true
That test build is bad (because of bug 288360).
Here's a fixed one
http://www.smfr.org/downloads/camino/Camino20050330_2_bug166932.zip
Just so everybody knows:

- repaint of multiple animated gifs is much much better. Bug 280982
- any page with animated objects paints much more optimal.
- scrolling a webpage feels much smoother.
- in this build Bug 268320, thankls to Bug 288222.
- typing in textfields with animated gifs on the same page is much much better,
but  there still remains a delay on long paragraphs. Bug 272954
- the same goes for a page with just a textfield, those also still have a slight
delay on large paragraphs, but tthere is a big difference noticable.
Oh the only regression i found was the flickering scrollbars on the bugzilla
search page when ever one mouse their mouse. Funky stuff, feels like a disco.
Opening or closing some sites, black background flashes.

Example above:http://www003.upp.so-net.ne.jp/woodenships/
Just for reference;
1) The problem showing above was seen with Simon's latest test build.
2) The problem seems not to be reproduced with 2005-03-31 nightly build.
The cursor placement in text fields has become flakey in Build 2005033108.  If
you move the insertion point in a bugzilla text field, keystrokes don't work at
first.  Click the mouse again and the insertion point takes hold and keystrokes
work.  This regression occurred last night.
OK, looks like comment 14 is related to core bug 289022.
Apple's response on the issue of making NSQuickDrawViews opaque is that it will
not work correctly. There are incompatibilities with the NSWindow update
mechanism and the way that NSQuickDrawView works which make it impossible to
reliably update opaque NSQDViews.

The workaround in the page is not suitable for shipping. QDFlushPortBuffer() is
a very expensive operation that we don't want to do very frequently, and, as
noted, it causes screen flashing.

I've attemped to write a QuickDrawView which wraps a GWorld around a CGImageRef
(so that both share the same pixel buffer), which works, but you have to draw
the CGImageRef at the end of every drawRect. This makes it quite a bit slower
than NSQuickDrawView.

There is no easy solution to this bug.
Comment on attachment 179015 [details] [diff] [review]
Another patch, mostly working

Flushing is evil and expensive, so we don't want to do this.
Attachment #179015 - Attachment is obsolete: true
This patch adds an early return to drawRect: if the rect to be drawn is
entirely covered by subviews (which will therefore draw over the top of this
area). It uses the less precise union of the update rect to avoid having to
iterate through all subviews for every one of the rects to be drawn.

This does good things for typing performance (bug 272954) and seems to be the
best solution to having to have non-opaque views so far.
Attachment #189462 - Flags: review?(pinkerton)
Would be good to get this in for 0.9.
Priority: -- → P2
Target Milestone: Camino1.2 → Camino0.9
Comment on attachment 189462 [details] [diff] [review]
Patch that short-circuits draws for areas obscured by subviews

r=pink. looks good i guess.
Attachment #189462 - Flags: review?(pinkerton) → review+
Perf is as good as we can get it with NSQuickDrawView.
Target Milestone: Camino0.9 → Future
Comment on attachment 189462 [details] [diff] [review]
Patch that short-circuits draws for areas obscured by subviews

This patch was checked in.
Attachment #189462 - Attachment is obsolete: true
*** Bug 303464 has been marked as a duplicate of this bug. ***
*** Bug 311373 has been marked as a duplicate of this bug. ***
*** Bug 323137 has been marked as a duplicate of this bug. ***
*** Bug 325311 has been marked as a duplicate of this bug. ***
*** Bug 328488 has been marked as a duplicate of this bug. ***
*** Bug 331340 has been marked as a duplicate of this bug. ***
Is having this bug open still useful? 

Seems like lots of performance bugs are duped against this one; do we know they all have this as the root cause?
(In reply to comment #29)
> Is having this bug open still useful? 

Why wouldn't it be? It's still a bug.
 
> Seems like lots of performance bugs are duped against this one; do we know they
> all have this as the root cause?

Anything related to our "hanging" when moving JS stuff is doing its thing definitely has the same cause. Most Flash perf goes to other existing bugs.

This bug would have been closed at the last checkin if it was "fixed". This is something Cairo may help with, if I'm understanding Cairo correctly (yes, I said it).
*** Bug 336387 has been marked as a duplicate of this bug. ***
*** Bug 341135 has been marked as a duplicate of this bug. ***
*** Bug 345641 has been marked as a duplicate of this bug. ***
*** Bug 353062 has been marked as a duplicate of this bug. ***
Hi:

So is there a resolution for bug 166932?

Hi:

I can transfer the bookmark of the web page associated with bug 353062. But it then periodically is non-responsive (i. e., I see the spinning object associated with the OS running an application.

The web page seems to be a countdown page that adjusts the time and has an object crossing the screen in a constant barrage of "snow".  

Is the problem caused by Camino rectifying the page faster that the OS can keep track?

Please let me know what the status is regarding this bug.

Thanks
The status of this bug is that it remains unresolved, as indicated by the fact that it is still open.  It's a Camino problem that is well understood but extremely difficult to fix at this point.
Is this something likely to be fixed (or hidden well) by Cairo? On pages from various dupes, perf is, seemingly, ten times better resulting in the actual use of web pages (yay).

I'm guessing the problem itself isn't actually fixed only hidden well, but I'm only guessing that because I don't know the code well.
As I understand it, we should be able (under Cairo) to actually mark opaque views as such.
QA Contact: winnie → page.layout
Target Milestone: Future → Camino2.0
Duplicate of this bug: 385187
So here's where we are currently on trunk:
- CHBrowserView is opaque
- ChildView is opaque
- BrowserWrapper isn't opaque, but given that it doesn't appear to actually do any drawing of its own it's not clear to me why it should be.

Simon, is there actually anything left to do here given that?
If ChildView is opaque on trunk, then you're done. Of course, this can only work if it's no longer an NSQuickDrawView.
Assignee: sfraser_bugs → nobody
Status: ASSIGNED → NEW
Yep, NSQuickDrawView is no more. Calling this FIXED based on that and the work you did here then.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Duplicate of this bug: 410690
Duplicate of this bug: 419738
You need to log in before you can comment on or make changes to this bug.