Closed
Bug 334411
Opened 19 years ago
Closed 14 years ago
Implement paint flashing
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla11
People
(Reporter: bzbarsky, Assigned: bas.schouten)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
3.07 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
924 bytes,
patch
|
bas.schouten
:
review+
roc
:
checkin+
|
Details | Diff | Splinter Review |
Someone who understands what regions cairo is actually repainting needs to adjust the patch from bug 220953 to work in cairo builds.
![]() |
Reporter | |
Updated•19 years ago
|
Flags: blocking1.9a1?
Updated•19 years ago
|
![]() |
Reporter | |
Updated•19 years ago
|
![]() |
Reporter | |
Comment 1•19 years ago
|
||
Not gonna block 1.9 on this.
roc, could we possibly do this in the viewmanager instead of widgets? That would also flash the area we really are repainting...
Flags: blocking1.9a1? → blocking1.9-
...and would be cross-platform, which would mean we'd stop having to rewrite it.
With our newfangled alpha support, we could even draw the actual update region in a translucent color, overlaying the page content. It would be a permanent thing on the rendered display, as opposed to just a flash, but I think that would actually be preferable. How's that sound?
(In reply to comment #3)
> With our newfangled alpha support, we could even draw the actual update region
> in a translucent color, overlaying the page content. It would be a permanent
> thing on the rendered display, as opposed to just a flash, but I think that
> would actually be preferable. How's that sound?
Wouldn't that mean that if I paint area A and then area B, both A and B have the "update" overlay, so I can't tell which one was the last one to be repainted?
It's hard to do a temporary flash from non-widget code because that stuff's all double buffered in the normal paint path. We could create a rendering context and do an immediate draw but I'd actually like to eliminate drawing outside of the paint event. I'm not sure what the right way to go is.
![]() |
Reporter | |
Comment 5•19 years ago
|
||
> It would be a permanent thing on the rendered display
That's not really desirable, because then we'd just end up with the whole window showing it... In my experience paint flashin is most useful for things like scrolling, DHTML, UI interaction, where every so often the whole thing gets invalidated.
For Xgl there's a little tool that does this for any and all applications (probably works in aiglx too). The only problem is that it shows damage due to scrolling as well as invalidation, which I don't want, but that may not worry other people. I think OSX has something similar.
A related question is whether we want the app to pause while flashing. Currently it does, which can be good and bad...
Comment 7•15 years ago
|
||
Do we really still not have paint flashing on X?
![]() |
Reporter | |
Comment 8•15 years ago
|
||
Last I checked, we do not.
Nor do we really have it on Mac, though QuartzDebug can help with that a bit.
Comment 9•14 years ago
|
||
Paint flashing belongs more in layers now than in Cairo drawing code; IIRC we have something approximating it too.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Comment 10•14 years ago
|
||
I don't see anything approximating this in the code. I'm going to try hacking this up as a learning exercise. I don't see a logical bottleneck in the Layer classes and my plan is to tack it on to gfxContext::Paint(). Will that work?
This probably needs to be done as part of bug 690064.
Assignee | ||
Comment 12•14 years ago
|
||
This patch introduces 'paint flashing' what is does is it draws a transparent 'shade' in a random color (varying per paint) over the area that was invalidated.
Attachment #574190 -
Flags: review?(roc)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Implement paint flashing in cairo builds → Implement paint flashing
Comment on attachment 574190 [details] [diff] [review]
Introduce paint flashing
Review of attachment 574190 [details] [diff] [review]:
-----------------------------------------------------------------
::: layout/base/FrameLayerBuilder.cpp
@@ +2130,5 @@
> aContext->Restore();
> }
> +
> +#ifdef DEBUG
> + if (Preferences::GetBool("nglayout.debug.paint_flashing", false)) {
Use AddBoolVarCache and make this non-#ifdef DEBUG
Assignee | ||
Comment 14•14 years ago
|
||
Updated as per review comments.
Attachment #574190 -
Attachment is obsolete: true
Attachment #574521 -
Flags: review?(roc)
Attachment #574190 -
Flags: review?(roc)
Attachment #574521 -
Flags: review?(roc) → review+
Comment 15•14 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/6235e0c97c3b
To save time/mistakes when merging, please could you set assignee + target milestone when landing on inbound (https://wiki.mozilla.org/Tree_Rules/Inbound#Please_do_the_following_after_pushing_to_inbound).
Thanks :-)
Assignee: nobody → bas.schouten
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
We should have done this originally
Attachment #594628 -
Flags: review?(bas.schouten)
Assignee | ||
Updated•13 years ago
|
Attachment #594628 -
Flags: review?(bas.schouten) → review+
Attachment #594628 -
Flags: checkin?
Attachment #594628 -
Flags: checkin? → checkin+
Comment 18•13 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•