User:CL

From Apache OpenOffice Wiki
Revision as of 12:40, 24 August 2006 by Thorsten (Talk | contribs)

Jump to: navigation, search

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

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. 

Status updates

2006-08-22

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 Behrens in m182. It implements nearly all bitmap operations that vcl needs for 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

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

BOOL ImplSVMainHook( BOOL * pbInit )
{
  EventLoopTimerRef aMainRunLoopTimerRef;

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

  RunApplicationEventLoop();

  return TRUE;   // indicate that ImplSVMainHook is implemented

}

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:

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

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

{office code}
ImplSVMain()
MainRunLoopForThreadedApps()
ImplSVMainHook()
SVMain()
main()

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

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

Screenshot of the day

Status: I optimized the AquaSalBitmap implementation. In my first emplementation I always created a 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 link how to get a pointer to the pixels inside the graphic card. I got that working but what I get was 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.

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);	
Personal tools