Last Comment Bug 343987 - [BeOS] Rendering context and other gfx rework
: [BeOS] Rendering context and other gfx rework
: fixed1.8.1.12
Product: Core Graveyard
Classification: Graveyard
Component: GFX: BeOS (show other bugs)
: Trunk
: Other BeOS
: -- normal (vote)
: ---
Assigned To: Sergei Dolgov
: QA timeless
Depends on:
  Show dependency treegraph
Reported: 2006-07-08 18:20 PDT by Sergei Dolgov
Modified: 2011-04-01 11:22 PDT (History)
1 user (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

patch (7.85 KB, patch)
2006-07-09 03:25 PDT, Sergei Dolgov
thesuckiestemail: review+
Details | Diff | Splinter Review
patch (1.90 KB, patch)
2006-07-10 13:46 PDT, Sergei Dolgov
thesuckiestemail: review+
Details | Diff | Splinter Review
patch (1.95 KB, patch)
2006-07-19 15:16 PDT, Sergei Dolgov
no flags Details | Diff | Splinter Review
patch for 1.8 branch (8.41 KB, patch)
2007-11-15 07:08 PST, Sergei Dolgov
doug: review+
samuel.sidler+old: approval1.8.1.12+
Details | Diff | Splinter Review

Description Sergei Dolgov 2006-07-08 18:20:40 PDT
1)Implement line styles (easy)
2)Investigate why there are problems if we use non-cached backbuffer
3)There were several methods added to nsI(gfx) since last time I did here big revision.
e.g. GetRange and other text block methods, GetNativeGraphicsData in RenderingContext (requires also new constant for BeOS in nsIRenderingContext).

Will look for more things we missed.
Comment 1 Sergei Dolgov 2006-07-09 03:25:40 PDT
Created attachment 228584 [details] [diff] [review]

First portion of changes.
Most innocent - 
1)adds missing implementation of line styles (still didn't apply that for ::Fill*() methods - as I'm unsure if mozilla expects some line style in filling)
2)Fixes signed-unsigned warning
3)Adds in outcommented form two methods for deleting/creating backbuffer instead permanent one. That's will be topic for following patches - put to work it properly.
Comment 2 tqh 2006-07-09 07:56:42 PDT
Comment on attachment 228584 [details] [diff] [review]
AFAIK it looks good, I wonder if the consts shouldn't maybe be all uppercase, what's the codestyle for that here?
Comment 3 Sergei Dolgov 2006-07-09 08:44:12 PDT
Checking in mozilla/gfx/src/beos/nsRenderingContextBeOS.cpp;
/cvsroot/mozilla/gfx/src/beos/nsRenderingContextBeOS.cpp,v  <--  nsRenderingContextBeOS.cpp
new revision: 1.60; previous revision: 1.59
Checking in mozilla/gfx/src/beos/nsRenderingContextBeOS.h;
/cvsroot/mozilla/gfx/src/beos/nsRenderingContextBeOS.h,v  <--  nsRenderingContextBeOS.h
new revision: 1.31; previous revision: 1.30
Comment 4 Sergei Dolgov 2006-07-09 17:48:39 PDT
In regard of printing transition to widget we need either to move there nsDeviceContext - like MacOS idi, or fix (add 	-I$(srcdir)/../../../widget/src/beos \ in INCLUDES section) and nsDeviceContextBeOS.h (add there #include nsDeviceContextSpecB.h )
Comment 5 Sergei Dolgov 2006-07-09 18:58:57 PDT
in case of bitmapped view to bitmapped view blit works very well and fast even with simplest less than effective byte-by byte copy code:
PRBool offscreen;
if (offscreen)
BBitmap *dstbitmap = destsurf->GetBitmap();
uint32 *src = (uint32 *)srcbitmap->Bits() + srcX + srcY*srcbitmap->BytesPerRow();
uint32 *dst = (uint32 *)dstbitmap->Bits() + drect.x +  drect.height*dstbitmap->BytesPerRow();
for(uint j = 0; j < drect.height; j++)
for(uint i = 0; i < drect.width; i++)
dst[i + j*dstbitmap->BytesPerRow()] = src[i + j*srcbitmap->BytesPerRow()];
needs addition of GetBitmap() method to nsDrawingSurfaceBeOS.

Writing it now from SeaMonkey with such code.
Comment 6 Sergei Dolgov 2006-07-09 19:29:35 PDT
Per comment #5:

Seems i was too fast for that report. Looks like bitmap-to-bitmap case is never happening, which means that we lack proxied buffering with separate bitmap proxy for each view and common backbuffer.

Situation needs investigation, and may have same reason as our inability to add-remove backbuffer permanently instead using cached.

Visible speedup I enjoyed in report may be caused by changes in nsWindow::OnPaint - rendering context and surface new interfaces i tried here.
Comment 7 Sergei Dolgov 2006-07-10 07:47:36 PDT
I catched part of problem, why we have troubles in painting if we create/destroy backbuffer at each paint, as Windows and Linux do.

CreateDrawingSurface supplies in such case aBounds which reflects size of rect to update/repaint, while cached backbuffer always had size of initial BView.
Left and Top of such aBounds are always 0, 0.

Then we create BView inside that little clipped surface, attach it to little bitmap and drawing there.
Probably something here goes wrong with coordinates - like layout/rendering context supplies onscreen BView-related coordinates, while we need mSurface related ones, when calling painting primitives - or ::CopyOffScreenBits does things wrong for some reason
Comment 8 Sergei Dolgov 2006-07-10 12:04:14 PDT
Well, problem is in nsRenderingContextBeOS::CopyOffScreenBits()

In case of little temporary backbuffers which are "placed" over arbitrary dirty rects of onscreenvew, we cannot get that bacbuffers-view clip region and put it
 as big onscreenview clip-region.

But if we ignore that flag, painting, inspite it works now in both cases of permanent or temporaty backbuffers, goes messy and stochastic.

So, our clipping region support is crap atm. And we do it in several places in widget and gfx.
Comment 9 Sergei Dolgov 2006-07-10 13:46:39 PDT
Created attachment 228715 [details] [diff] [review]

Sets proper clipping for CopyOffscreenBits.
Allows to use temporary backbuffers, which reduces RAM-consumption, but should be estimated with some tests in regard of drawing speed.
Also, I hope, allows to use native BView::Scroll() in future.

Comment 10 tqh 2006-07-10 22:59:47 PDT
Comment on attachment 228715 [details] [diff] [review]
Looks ok AFAIK.
Comment 11 Sergei Dolgov 2006-07-11 06:17:34 PDT
Checking in mozilla/gfx/src/beos/nsRenderingContextBeOS.cpp;
/cvsroot/mozilla/gfx/src/beos/nsRenderingContextBeOS.cpp,v  <--  nsRenderingContextBeOS.cpp
new revision: 1.61; previous revision: 1.60
Comment 12 Sergei Dolgov 2006-07-19 14:23:32 PDT
According to comment in OS2 code
looks like 0-sized regions are possible and actually in use to draw nothing.

Wondering if it is better just return from drawing primitive in beginning if one of region frame dimensions is 0, instead drawing it with clipping.

In our case it cab be easily achieved
Comment 13 Sergei Dolgov 2006-07-19 15:16:16 PDT
Created attachment 229898 [details] [diff] [review]

Patch. Changes a bit LockAndUpdateView() code.
If there is mClipRegion and if some size  of native region frame is less-equal 0,
it returns false immediatelly.
It allows us to avoid any calculation and app_server poking in all drawing primitives, as we use that method everywhere we draw.
Comment 14 Sergei Dolgov 2007-11-13 03:43:51 PST
CopyOffscreenBits fix and maybe other changes need backporting to branch.
Comment 15 Sergei Dolgov 2007-11-15 07:08:33 PST
Created attachment 288839 [details] [diff] [review]
patch for 1.8 branch

two first patches together adapted to branch.
Comment 16 Sergei Dolgov 2007-11-15 16:37:29 PST
Comment on attachment 229898 [details] [diff] [review]

In current form this 3rd patch when applied creates drawing artifacts, if you scroll pages with pressed middle-button drag.
So obsoleting.
Comment 17 Doug Shelton 2007-11-15 20:22:42 PST
Comment on attachment 288839 [details] [diff] [review]
patch for 1.8 branch

reviewed, applied against branch and tested.  We've missed the cutoff, so requesting approval for
Comment 18 Samuel Sidler (old account; do not CC) 2007-12-17 15:37:15 PST
Comment on attachment 288839 [details] [diff] [review]
patch for 1.8 branch

Approved for, a=ss for release-drivers.
Comment 19 Sergei Dolgov 2007-12-17 23:17:59 PST
Checking in mozilla/gfx/src/beos/nsRenderingContextBeOS.cpp;
/cvsroot/mozilla/gfx/src/beos/nsRenderingContextBeOS.cpp,v  <--  nsRenderingContextBeOS.cpp
new revision:; previous revision:
Checking in mozilla/gfx/src/beos/nsRenderingContextBeOS.h;
/cvsroot/mozilla/gfx/src/beos/nsRenderingContextBeOS.h,v  <--  nsRenderingContextBeOS.h
new revision:; previous revision:
Comment 20 Joe Drew (not getting mail) 2011-04-01 11:21:40 PDT
We don't support BeOS any more.
Comment 21 JP Rosevear [:jpr] 2011-04-01 11:22:26 PDT
In the graveyard, code referred to doesn't exist to be fixed.

Note You need to log in before you can comment on or make changes to this bug.