|
|
| Line 1: |
Line 1: |
| − | My log of the vcl bitmap and widget stuff to the QUARTZ API | + | My personal list of todo stuff and current status |
| | | | |
| − | Nick on irc.freenode.net : ChristianL | + | Nick on irc.freenode.net : CL |
| | | | |
| − | Mail : mac AT fishbyte.de | + | Mail : christian.lippka AT sun.com |
| | | | |
| | == DISCLAIMER == | | == DISCLAIMER == |
| Line 15: |
Line 15: |
| | == Status updates == | | == Status updates == |
| | | | |
| − | === [[2006]]-[[09-03]] === | + | == TODO == |
| | | | |
| − | What a relief. I got source level debuging working under xcode 2.3 at last.
| + | === Open ODF 1.2 features === |
| | | | |
| − | First you must have xcode 2.3 or newer, as we need the new dwarf debug format. Then you
| + | Auto shrink text in shapes [[http://lists.oasis-open.org/archives/office/200701/msg00025.html OASIS]] |
| − | also must have a full build of cws aquavcl01. Install the office from the .dmg you find
| + | Status: Desired for OOo3.0 |
| − | in instsetoo_native project.
| + | |
| | | | |
| − | I now assume you installed your OOo in /cws/OOo and have your cws projects in /cws/aquavcl01. If not please adapt the pathes according to your environment.
| + | Proposals for tables in presentations/drawings [[http://lists.oasis-open.org/archives/office/200701/msg00031.html OASIS]] |
| | + | Status: Planed for OOo3.0 |
| | | | |
| − | <pre>
| + | Proposal: last visited page interaction [[http://lists.oasis-open.org/archives/office/200701/msg00042.html OASIS]] |
| − | > cd /cws/OOo/Contents/MacOS
| + | Status: Planed for OOo3.0 |
| − | > rm droplet
| + | |
| − | > ln -s program/soffice.bin droplet
| + | |
| − | > ln -s program/* ./
| + | |
| − | </pre>
| + | |
| | | | |
| − | # Now start XCode, create a new project and choose "Empty Project".
| + | How to add animations for shapes on master pages [[http://lists.oasis-open.org/archives/office/200702/msg00123.html OASIS]] |
| − | # Under "Project" choose "Add New Custom Executable"
| + | Status: Planed for OOo 3.0 |
| − | # Choose soffice.bin as a name and /cws/OOo/Contents/MacOS/droplet as path
| + | |
| − | # Press "Finish"
| + | |
| − | # Now configure your custom executable, in the first pane choose "Custom directory" and enter /cws/OOo/Contents/MacOS/program
| + | |
| − | # Click on "Arguments" and add the argument "-nofirststartwizard"
| + | |
| | | | |
| − | Now you should be able to fire up the debugger in xcode and start debuging.
| + | Proposal for rounded corners of rects (draw:corner-radius) [[http://lists.oasis-open.org/archives/office/200703/msg00206.html OASIS]] |
| | + | Status: Currently not planed for OOo |
| | | | |
| − | But for efective debuging you need source level debug information for the modules you want to debug.
| + | Add glue points to 3D objects [[http://lists.oasis-open.org/archives/office/200705/msg00102.html OASIS]] |
| − | First, since I have not yet commit it to the cws, you need to open /cws/aquavcl01/solenv/inc/unxmacx.mk and find
| + | Status: Currently not planed for OOo |
| − | the following line
| + | |
| | | | |
| − | <pre> | + | Proposal for <anim:audio> [[http://lists.oasis-open.org/archives/office/200705/msg00128.html OASIS]] |
| − | CFLAGS=-fsigned-char -fmessage-length=0 -malign-natural -c
| + | Status: Already integrated in OOo 2.0 |
| − | </pre>
| + | |
| | | | |
| − | change it to
| + | Proposal to enhance hyperlinks to support shapes [[http://lists.oasis-open.org/archives/office/200707/msg00061.html OASIS]] |
| | + | Status: Import planned for OOo 2.4, export desired for OOo 3.0 |
| | | | |
| − | <pre>
| + | Proposal for extending stroke dashes [[http://lists.oasis-open.org/archives/office/200708/msg00006.html OASIS]] |
| − | CFLAGS=-fsigned-char -fmessage-length=0 -malign-natural -gdwarf-2 -c
| + | Status: Already integrated in OOo 2.0 |
| − | </pre>
| + | |
| | | | |
| − | Now lets say you want to debug vcl.
| + | <svg:desc> and <svg:title> for drawing pages [[http://lists.oasis-open.org/archives/office/200710/msg00065.html OASIS]] |
| | + | Status: Still under discussion in the TC |
| | | | |
| − | <pre>
| + | Layer-set per page [[http://lists.oasis-open.org/archives/office/200705/msg00132.html OASIS]] |
| − | > cd /cws/aquavcl01/vcl
| + | Status: Still under discussion in the TC |
| − | > rm -fr unxmacxi.pro
| + | |
| − | > build debug=t
| + | |
| − | > cp unxmacxi.pro/lib/*.dylib /cws/OOo/Contents/MacOS/program
| + | |
| − | </pre>
| + | |
| | | | |
| − | Restart your debuging session and now you should be able to set breakpoints and step through source code instead of assembler. You don't have to compile whole projects with debug=t, if you need only debug one function you can touch that cxx file and only build that single file with debug=t.
| + | Points are integers in ODF,but floating-point in SVG [[http://lists.oasis-open.org/archives/office/200703/msg00243.html OASIS]] |
| − | | + | Status: Still under discussion in the TC |
| − | === [[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 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]] ===
| + | |
| − | | + | |
| − | [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:Development]] |
| − | [[Category:Aqua]] | + | [[Category:Impress]] |
| − | [[Category:MacOSX]] | + | [[Category:Draw]] |
