My log of the vcl bitmap and widget stuff to the QUARTZ API

Nick on irc.freenode.net : ChristianL

Mail : mac AT fishbyte.de

== DISCLAIMER ==
<pre>
This is my personal wiki. Everything I write here
may be wrong, stupid, incorrect, harmful or worse.
The views expressed on this page aren't (necessarily)
the views of Sun Microsystems Inc.
</pre>

== Status updates ==

=== [[2006]]-[[08-22]] ===

[http://www.fishbyte.de/rasterops_notworking.png Screenshot of the day]

Had fun today implementing raster operations for the aqua output device. I have yet to write some background about raster operations, but to make it short just look at the screenshot of the day above. This happens when raster operations are not working. The gradient fill should be only visible inside the circle.

I have nearly all of the needed implementation done, but it does not yet work as expected. To my surprise it was very easy to implement raster operations on a system that does not provide them in the rendering engine. I used the basebmp project, newly introduced by Thorsten Behrends in m182. It implements nearly all bitmap operations that vcl needs for in memory bitmaps. So what I do is that if I need to paint with the raster mode XOR, I create a basebmp::BitmapDevice on demand that shares the same memory buffer with the CGBitmapContext from QUARTZ that I use for the offscreen rendering. When done painting to the CGBitmapContext by using the basebmp::BitmapDevice I blit the affected area from the offscreen bitmap context to the CGContext of the window. I suspect that the last part is not working correctly as I see only a black circle. Have to debug that later.

=== [[2006]]-[[08-21]] ===

[http://www.fishbyte.de/menu.png Screenshot of the day]

Today I did a resync of aquavcl01 to m182.

I looked at the sample implementation of how we could use the RunApplicationEvent() method to install some basic needed CarbonEvent handlers. The problem with that is that this call only returns when the application is finished.
So basicly what that sample code did and what I added to the ImplSVMainHook() method is the following

<pre>
BOOL ImplSVMainHook( BOOL * pbInit )
{
EventLoopTimerRef aMainRunLoopTimerRef;

(void) InstallEventLoopTimer( GetCurrentEventLoop(), 0, 0,
NewEventLoopTimerUPP( MainRunLoopForThreadedApps ),
NULL, &aMainRunLoopTimerRef );

RunApplicationEventLoop();

return TRUE; // indicate that ImplSVMainHook is implemented

}
</pre>

The ImplSVMainHook() function is directly called from the applicaions main function. It is an alternative
for the call to ImplSVMain(). So when the ''return TRUE;'' statement is hit, the application
exits. What RunApplicationEventLoop() does is init all default handlers and then call the
registered timer handler at MainRunLoopForThreadedApps(). This is the code:

<pre>
static pascal void MainRunLoopForThreadedApps( EventLoopTimerRef inTimer, void *inUserData )
{
BOOL bRet = ImplSVMain();
QuitApplicationEventLoop();
}
</pre>

And as you can see, all that we do is call the original ImplSVMain() instead of the ImplSVMainHook() which starts the actual office. So the stack currently is

<pre>
{office code}
ImplSVMain()
MainRunLoopForThreadedApps()
ImplSVMainHook()
SVMain()
main()
</pre>

So we are still inside the call to RunApplicationEventLoop() but we can also query for all events ourselfs. As soon as ImplSVMain() exits, we tell QuitApplicationEventLoop() to end the application event loop, therefore exiting ImplSVMainHook and quiting the application for good.

The results, as you can see on my screenshot above are realy cool. Rulers started to paint themselfs, I could create actuall shapes in impress, many repaint problems vanished. I even could start some java wizards without problems. Then I also compiled with pavels native menus and they worked! Great work pavel.

Eric and Pierre are currently implementing more native drawn widgets so expect some real cool screenshots soon.

=== [[2006]]-[[08-19]] ===

[http://www.fishbyte.de/toolbar_bitmaps.png Screenshot of the day]

Not much update today. I managed to find my transparency problem yesterday night. You can see the
results on the screenshot above. I cleaned up my code a bit and commit everything to vcl. I also implemented that each window now also have an offscreen CGBitmapContext. All drawings are rendered both to the window and the offscreen bitmap. If pixels needs to be read, the offscreen bitmap is used.

If you want to check it out, update vcl/aqua and also delete your ~/Library/Application Support/OpenOffice.org 2.0/users directory as it contains cached images that are broken.

Currently the office loops as soon as a multi line text is visible. It loops somewhere in that ATSULayout stuff. I have to ask Stephan on monday if he may have a look as this crash is annoying.

=== [[2006]]-[[08-18]] ===

[http://www.fishbyte.de/nativecontrols.png Screenshot of the day]

Status: I optimized the AquaSalBitmap implementation. In my first emplementation I always created a [http://developer.apple.com/documentation/GraphicsImaging/Reference/CGBitmapContext/Reference/reference.html CGBitmapContext] with either 16 or 32 bit. This made it fast and easy to create CGImage for rendering. The cost was that for AquaSalBitmap::AquireBuffer I had to convert the mac format back to VCL for 1,4,8 and 24 bit formats. This also is a drawback because many SalBitmaps are not even used for drawing. For example when loading a bitmap from a file a SalBitmap with the original file format is created. Then this is copied via the Create( const SalBitmap& rSalBmp, SalGraphics* pGraphics ) to have the same format as the current display. Also alpha masks are never drawn directly.

As a consequence, I now always store the bitmap data in a memory puffer in the format that is requested by VCL. Only if the bitmap is to be drawn on screen I create a CGBitmapContext and only convert the format if needed.

The biggest issue at the moment besides not having any raster operations is the problem with

* AquaSalGraphics::getBitmap
* AquaSalGraphics::copyBits
* AquaSalGraphics::copyArea

This methods need access to the pixels on screen. This currently is used sometimes for transparency in bitmaps
and also for late 80's style scrolling speedups. Getting pixels from an on screen window on the mac would
require to directly access the buffer inside the graphic card.

Pavel send me this marvelous [http://lists.apple.com/archives/cocoa-dev/2005/Jun/msg02321.html link] how to get a pointer to the pixels inside the graphic card. I got that working but what I get was [http://www.fishbyte.de/gamma_problem.png this].

The problem is that the mac does a gamma correctur. So what you see is what you get but not what you want.
The image above shows a 32x32 area at the bottom right that is a copy of the same area at the top left.
You can see that it is much brighter. Thats because on second paint it again is gamma corrected. Therefore
the pixel information from the graphic card is not usable, unless we undo the gamma correction. But that slows
a slow method down even more and also we lose precision.

So I rethink about my first aproach to this problem where I did all rendering to an offscreen CGBitmapContext
and then blitting that to the window. This worked like a charm since you can access the unaltered pixel from
a CGBitmapContext in contrast to a CGContext from a window.

There is a problem with this aproach. If we want to let the mac render native widgets we can either use the draw methods of the controls itself or the appereance manager. But both only render directly in a window. Therefore the pixels of the controls would not be present in the offscreen CGBitmapContext and could be overridden if we blit that part of the offscreen bitmap to the window.

My current idea is a mixed solution where we have a CGBitmapContext for each window and render twice. Once in the window directly and once in the offscreen bitmap. The offscreen bitmap is then only used to read pixels. This will be a significant overhead but on the other hand we will need an offscreen bitmap sooner or later to implement raster operations.

== Open Issues ==
* implement raster operations
* make transparency bitmaps work (done)
* implement Invert methods
* implement GetPixel method
* check if text is also drawn to the offscreen bitmap

== Todo ==
* Write something about raster operations

== Code fragments ==

The following code creates a AquaSalBitmap from the window area (nX,nY,nDX,nDY). Problem is that the resulting pixels are already gamma corrected. Painting them again causes a second gamma correction.

<pre>
CGrafPtr windowPort( GetWindowPort(mrWindow) );
LockPortBits(windowPort);

PixMapHandle thePixels( GetPortPixMap(windowPort) );
LockPixels(thePixels );

Rect windowBounds;
GetWindowPortBounds ( mrWindow, &windowBounds);

Rect structureWidths;
// Obtains the width of the structure region on each edge of a window.
GetWindowStructureWidths ( mrWindow, &structureWidths );

// exclude left and top window border
nX += structureWidths.left;
nY += structureWidths.top;

AquaSalBitmap* pBitmap = new AquaSalBitmap;
ipBitmap->Create( windowBounds.right - windowBounds.left,
windowBounds.bottom - windowBounds.top,
GetBitCount(), GetPixRowBytes(thePixels),
reinterpret_cast< sal_uInt8* >( GetPixBaseAddr(thePixels)),
nX, nY, nDX, nDY );

UnlockPixels (thePixels);
UnlockPortBits(windowPort);
</pre>

[[Category:Porting]]
[[Category:Development]]
[[Category:Aqua]]
[[Category:MacOSX]]

User:CL

2006-08-22T00:04:53Z

Cl: update 2006-08-21

My log of the vcl bitmap and widget stuff to the QUARTZ API

Nick on irc.freenode.net : ChristianL

Mail : mac AT fishbyte.de

== DISCLAIMER ==
<pre>
This is my personal wiki. Everything I write here
may be wrong, stupid, incorrect, harmful or worse.
The views expressed on this page aren't (necessarily)
the views of Sun Microsystems Inc.
</pre>

== Status updates ==

=== [[2006]]-[[08-21]] ===

[http://www.fishbyte.de/menu.png Screenshot of the day]

Today I did a resync of aquavcl01 to m182.

I looked at the sample implementation of how we could use the RunApplicationEvent() method to install some basic needed CarbonEvent handlers. The problem with that is that this call only returns when the application is finished.
So basicly what that sample code did and what I added to the ImplSVMainHook() method is the following

<pre>
BOOL ImplSVMainHook( BOOL * pbInit )
{
EventLoopTimerRef aMainRunLoopTimerRef;

(void) InstallEventLoopTimer( GetCurrentEventLoop(), 0, 0,
NewEventLoopTimerUPP( MainRunLoopForThreadedApps ),
NULL, &aMainRunLoopTimerRef );

RunApplicationEventLoop();

return TRUE; // indicate that ImplSVMainHook is implemented

}
</pre>

The ImplSVMainHook() function is directly called from the applicaions main function. It is an alternative
for the call to ImplSVMain(). So when the ''return TRUE;'' statement is hit, the application
exits. What RunApplicationEventLoop() does is init all default handlers and then call the
registered timer handler at MainRunLoopForThreadedApps(). This is the code:

<pre>
static pascal void MainRunLoopForThreadedApps( EventLoopTimerRef inTimer, void *inUserData )
{
BOOL bRet = ImplSVMain();
QuitApplicationEventLoop();
}
</pre>

And as you can see, all that we do is call the original ImplSVMain() instead of the ImplSVMainHook() which starts the actual office. So the stack currently is

<pre>
{office code}
ImplSVMain()
MainRunLoopForThreadedApps()
ImplSVMainHook()
SVMain()
main()
</pre>

So we are still inside the call to RunApplicationEventLoop() but we can also query for all events ourselfs. As soon as ImplSVMain() exits, we tell QuitApplicationEventLoop() to end the application event loop, therefore exiting ImplSVMainHook and quiting the application for good.

The results, as you can see on my screenshot above are realy cool. Rulers started to paint themselfs, I could create actuall shapes in impress, many repaint problems vanished. I even could start some java wizards without problems. Then I also compiled with pavels native menus and they worked! Great work pavel.

Eric and Pierre are currently implementing more native drawn widgets so expect some real cool screenshots soon.

=== [[2006]]-[[08-19]] ===

[http://www.fishbyte.de/toolbar_bitmaps.png Screenshot of the day]

Not much update today. I managed to find my transparency problem yesterday night. You can see the
results on the screenshot above. I cleaned up my code a bit and commit everything to vcl. I also implemented that each window now also have an offscreen CGBitmapContext. All drawings are rendered both to the window and the offscreen bitmap. If pixels needs to be read, the offscreen bitmap is used.

If you want to check it out, update vcl/aqua and also delete your ~/Library/Application Support/OpenOffice.org 2.0/users directory as it contains cached images that are broken.

Currently the office loops as soon as a multi line text is visible. It loops somewhere in that ATSULayout stuff. I have to ask Stephan on monday if he may have a look as this crash is annoying.

=== [[2006]]-[[08-18]] ===

[http://www.fishbyte.de/nativecontrols.png Screenshot of the day]

Status: I optimized the AquaSalBitmap implementation. In my first emplementation I always created a [http://developer.apple.com/documentation/GraphicsImaging/Reference/CGBitmapContext/Reference/reference.html CGBitmapContext] with either 16 or 32 bit. This made it fast and easy to create CGImage for rendering. The cost was that for AquaSalBitmap::AquireBuffer I had to convert the mac format back to VCL for 1,4,8 and 24 bit formats. This also is a drawback because many SalBitmaps are not even used for drawing. For example when loading a bitmap from a file a SalBitmap with the original file format is created. Then this is copied via the Create( const SalBitmap& rSalBmp, SalGraphics* pGraphics ) to have the same format as the current display. Also alpha masks are never drawn directly.

As a consequence, I now always store the bitmap data in a memory puffer in the format that is requested by VCL. Only if the bitmap is to be drawn on screen I create a CGBitmapContext and only convert the format if needed.

The biggest issue at the moment besides not having any raster operations is the problem with

* AquaSalGraphics::getBitmap
* AquaSalGraphics::copyBits
* AquaSalGraphics::copyArea

This methods need access to the pixels on screen. This currently is used sometimes for transparency in bitmaps
and also for late 80's style scrolling speedups. Getting pixels from an on screen window on the mac would
require to directly access the buffer inside the graphic card.

Pavel send me this marvelous [http://lists.apple.com/archives/cocoa-dev/2005/Jun/msg02321.html link] how to get a pointer to the pixels inside the graphic card. I got that working but what I get was [http://www.fishbyte.de/gamma_problem.png this].

The problem is that the mac does a gamma correctur. So what you see is what you get but not what you want.
The image above shows a 32x32 area at the bottom right that is a copy of the same area at the top left.
You can see that it is much brighter. Thats because on second paint it again is gamma corrected. Therefore
the pixel information from the graphic card is not usable, unless we undo the gamma correction. But that slows
a slow method down even more and also we lose precision.

So I rethink about my first aproach to this problem where I did all rendering to an offscreen CGBitmapContext
and then blitting that to the window. This worked like a charm since you can access the unaltered pixel from
a CGBitmapContext in contrast to a CGContext from a window.

There is a problem with this aproach. If we want to let the mac render native widgets we can either use the draw methods of the controls itself or the appereance manager. But both only render directly in a window. Therefore the pixels of the controls would not be present in the offscreen CGBitmapContext and could be overridden if we blit that part of the offscreen bitmap to the window.

My current idea is a mixed solution where we have a CGBitmapContext for each window and render twice. Once in the window directly and once in the offscreen bitmap. The offscreen bitmap is then only used to read pixels. This will be a significant overhead but on the other hand we will need an offscreen bitmap sooner or later to implement raster operations.

== Open Issues ==
* implement raster operations
* make transparency bitmaps work (done)
* implement Invert methods
* implement GetPixel method
* check if text is also drawn to the offscreen bitmap

== Todo ==
* Write something about raster operations

== Code fragments ==

The following code creates a AquaSalBitmap from the window area (nX,nY,nDX,nDY). Problem is that the resulting pixels are already gamma corrected. Painting them again causes a second gamma correction.

<pre>
CGrafPtr windowPort( GetWindowPort(mrWindow) );
LockPortBits(windowPort);

PixMapHandle thePixels( GetPortPixMap(windowPort) );
LockPixels(thePixels );

Rect windowBounds;
GetWindowPortBounds ( mrWindow, &windowBounds);

Rect structureWidths;
// Obtains the width of the structure region on each edge of a window.
GetWindowStructureWidths ( mrWindow, &structureWidths );

// exclude left and top window border
nX += structureWidths.left;
nY += structureWidths.top;

AquaSalBitmap* pBitmap = new AquaSalBitmap;
ipBitmap->Create( windowBounds.right - windowBounds.left,
windowBounds.bottom - windowBounds.top,
GetBitCount(), GetPixRowBytes(thePixels),
reinterpret_cast< sal_uInt8* >( GetPixBaseAddr(thePixels)),
nX, nY, nDX, nDY );

UnlockPixels (thePixels);
UnlockPortBits(windowPort);
</pre>

[[Category:Porting]]
[[Category:Development]]
[[Category:Aqua]]
[[Category:MacOSX]]

User:CL

2006-08-19T21:12:57Z

Cl: Update 2006-08-19

User:CL

2006-08-18T13:23:39Z

Cl:

User:CL

2006-08-18T13:09:42Z

Cl:

2006-03-09T14:54:21Z

Cl:

ODF Documents are a zipped archive of XML files along with some assorted information and pictures. Reading and parsing the XML constitutes a chunk of the time spent in opening documents. Below is an analysis of XML processing.

We use a suite of 60 [[Performance Related Test Documents]]. The content.xml for each has been extracted for XML-only tests.

Niklas and Florian have prototyped a test component, which tokenizes XML tags, and passes tokens around. This saves string allocation times and provides speedup.(FastXML)

== Comparisons ==
* Compare OpenOffice TestXML and TestFastXML for doc sample
* Compare different XML parsers & APIs in terms of processing content.xml
* Compare time spent in XML parsing, building document model, and rendering

== Methodology ==
* Time is measured in the same way for each test - This is based on Time::GetSystemTicks
* File handling and parsing is done as similar as possible - within allowances of API differences.
* Only C and C++ parsers are considered - Java based parsers/wrappers are excluded.

== Results ==
* FastXML provides good speedup, across the test suite.
* libxml2 (SAX API) is the fastest from a pure parsing point of view.
** libxml2 (Reader/processNode) is slower, but comparable to expat
** expat is faster than xerces (SAX & SAX2) as well as OO.o.
** OO.o parser has some UNO interface overhead (to be measured)

== Ongoing Work ==
* Performance counter to measure proportion of time spent in:
*# Opening & uncompressing container files
*# XML Parser setup
*# Actual Parsing
*# String Allocation
*# Building Doc Model
*# Rendering
*# replace expat with [[libxml2]] to compare performance in office, currently not working for all files
== Data ==
The [[Image:Xml-load-compare.ods|spreadsheet]].