Closed Bug 305028 Opened 19 years ago Closed 19 years ago

Get Cairo working on OS/2

Categories

(Core Graveyard :: GFX: OS/2, defect)

Product:
Core Graveyard
Component:
GFX: OS/2
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mozilla, Assigned: mozilla)

References

Details

Attachments

(1 file, 6 obsolete files)

Updated patch
8.50 KB, patch
benjamin
: review+
mkaply
: superreview+
Details | Diff | Splinter Review 
Now that Doodle has ported Cairo to OS/2 we can start integrating it into
Mozilla. It needs the three OS/2 specific files in gfx/cairo/cairo/src, changes
to that Makefile.in, some changes in layout/svg/renderer/cairo/src where the
XP_OS2 branches are needed, changes to the build environment because it depends
on FreeType, FontConfig, and Expat.

Actually, I completed the changes and I can indeed display SVG with Cairo now,
but there are still problems (like text not displaying, unexplained crashes) and
the changes I made are ugly (hardcoded paths etc.). I hope I can upload the
first patch next weekend.
First part of the patch. Make the necessary changes in configure.in, add three
files to gfx/cairo/cairo/src/, and add OS/2 lines to Makefile.in and
cairo-features.h.in in the same dir.
Attached patch Patch for cairo (layout) (obsolete) — — Splinter Review 
This makes the necessary changes in layout: Add required libs to
layout/build/Makefile.in, add gfx includes in
layout/svg/renderer/src/cairo/Makefile.in, and a first try at the necessary
changes in layout/svg/renderer/src/cairo/nsSVGCairoCanvas.cpp.

In the latter file the "real" change is the one around
cairo_os2_surface_create. The problem is that as far as I understand we would
have to release that presentation handle (at the moment called mHPS) somewhere.
That's what I tried in the parts of the patch that are commented.
Well, the only other instance of GetPS() does not release the handle but when
running my Cairo-SVG enabled build I noticed that for every redraw (like when I
resize the window while looking at
http://www.croczilla.com/svg/samples/lion/lion.svg>) several MB of RAM are
allocated until shared (?) RAM is exhausted and Mozilla just dies.
I should mention that these patches are against the 1.8 branch. As the trunk
just moved to Cairo 0.9.1+ which is not yet ported to OS/2 we have to wait with
that a bit.

Build instructions:
- Download the package containing the required extra 
  libraries (FreeType, FontConfig, Expat). For use with
  for GCC 3.2.2 I uploaded one containing all of them to
    http://weilbacher.org/temp/freetype_etc_for_OS2_cairo.zip
  Unpack that to somewhere like f:\Mozilla\freetype.
- Add these variables to the environment:
    set FREETYPE=f:\Mozilla\freetype
    set FREETYPE2=f:/Mozilla/freetype
    set FONTCONFIG=f:\Mozilla\freetype
    set FONTCONFIG2=f:/Mozilla/freetype
  (well, only the ones with forward slashes are necessary)
- Start compilation after adding 
    ac_add_options --enable-svg
  to .mozconfig.

Users then still need to add the two DLLs contained in the
freetype_etc_for_OS2_cairo.zip package to LIBPATH before being able to start the
browser.

Finally, I should note that since I am running SeaMonkey with this configuration
I have experienced several crashes, especially in nsSVGOuterSVGFrame::Paint and
nsSVGImageFrame::PaintSVG. I think they are unrelated, but if anyone can find a
reason in the above patches why I should see crashes in those methods when I
don't even have an SVG graphic on the screen, please speak up.
Version: Trunk → 1.8 Branch
Another question: The sizes that I derive from the nsIRenderingSurface called
ctx with GetDimensions() are strange, they don't change when I resize the
browser, and are larger than the browser, although no scrollbars appear that
would tell me that the SVG area is larger... Is that how it is supposed to be?
(There seem to be problems with the scrollbars when displaying SVG content on
its own, the OS/2 version just seems to follow what I see on Linux in that respect.)
To answer myself: no, constant sizes are not normal. I just made a new GTK2
build and there the surface mWidth and mHeight change when I resize the window
or move points on an interactive SVG page.
Mike, can you tell me what is going on? Is nsDrawingSurfaceOS2 not the correct
class to use?
(In reply to comment #5)
> To answer myself: no, constant sizes are not normal. I just made a new GTK2
> build and there the surface mWidth and mHeight change when I resize the window
> or move points on an interactive SVG page.
> Mike, can you tell me what is going on? Is nsDrawingSurfaceOS2 not the correct
> class to use?

The best explanation of how the gfx stuff works on OS/2 is this old stuff:

http://www.mozilla.org/ports/os2/code_docs/wzgfx.html

Not sure exactly what you are looking for...
Attached patch another cairo patch (obsolete) — — Splinter Review 
Here is the approach I took to this.  It is using the current trunck (as of
8-24).
There are some parts in the patch that are in Bug 305841 due to incompatibility
in expat modules.
https://bugzilla.mozilla.org/attachment.cgi?id=193771&action=edit
So, Doodle's Cairo v0.6 works with the current trunk Cairo which is v0.9.1+?
There should not be any need to link to expat which is only required by
fontconfig AFAICS. But where in the tree are expat and freetype (and
fontconfig?) located so that we can use them and what .mozconfig entries do you
use to get them built? Or where else do you get the -lfreetype etc. from? Also,
why did you enable the PNG/PS/PDF output? Is there any code that uses it on OS/2
but not on other platforms?

I took a look at the old documents that Mike pointed me to. If I believe them we
should be using a HDC instead of a HPS for that surface but there are no
functions to really do that. I still have to look a bit harder, but it seems to
me that the important part of nsDrawingSurfaceOS2 (like size reporting) is
similar to the version on Windows (which doesn't have this on/off screen
division, though).
I didn't use the cairo lib file.  I put Doodle's surface file and headers into
the v.0.9.1+ directory under Moz and updated the makefile.in (this seems to work).
The reason I did the PS/PDF/PNG was simply because that makes the
cairo-features.h that is built by Moz to match the one that Doodle had.  
I built freetype 2.1.9 here while back so had the lib and headers already... I
had to build fontconfig which required expat (when I then built Moz the
fontconfig libs then looked for the freetype and expat libs -- probably
something that I could have built differently but even so I think the library
name change for expat in Moz is appropriate).   
I originally tried to build using --enable-system-cairo but the cairo.lib did
not have _ decoration.  On IRC the sense of things is that --enable-system-cairo
is going away though I think it would have been a better option for us.
Not sure if it had already been tried but I just built with --enable-canvas and
it seems to work.  If this page is a test it does anyway:
http://www.extensionsmirror.nl/peter6/canvas.html
Wondering if Doodles patches shouldn't be applied upstream at
http://cairographics.org/. I might be wrong but my understanding is that Mozilla
synchs with upstream quite regularly. I do have patches for configure.in and
src/makefile.am to build Cairo with the configure + make route.(only working for
static builds)
I have been fooling around with --enable-system-cairo so wanted all the
pkgconfig files so Mozilla's configure could find them. Just started doing some
patches when I came across this bug and Peter already has submitted my patch
<gr> though he has included much more then I did.
Oh by the way Cairo is now released at version 1.0
Doodle told me that he had tried to get the OS/2 files (and some other patches)
integrated into cairo but the maintainers were not interested. He is working to
keep OS/2 versions updated on his own and will probably release 1.0 soon.
Then he needs to give the maintainers a MUCH harder time. It is OPEN source
after all...
I am still investigating why I get the strange widths and heights in
nsSVGCairoCanvas::Init. Can anyone tell me why I can use methods GetPS() and
GetDimensions() of the class nsDrawingSurfaceOS2 but I cannot use NS2PM_ININ,
NS2PM_INEX, or NS2PM although they are defined in the same class as public? I
always get unresolved externals when linking gklayout. I can add those symbols
to gfx_os2.def, compile in gfx\src\os2, copy gfx_os2.lib to dist\lib, and add
-lgfx_os2 to link it but then my browser doesn't start up any more and I just
don't get the difference between the functions that work and the ones that don't.
I think the problem is that we need an nsIDrawingSurfaceOS2.h
I am currently building using Doodle's updates using 1.0.2 files.  These files are on netlabs (currently in incoming).  The one thing I have noticed (saw it before but it did not register) is that colors are wrong.  The lion.svg link in comment #2 is a light blue for instance.  The canvas link in comment #10 has blue and red reversed and the yellow is the light blue.  Peter, do you see this or were some of your fixes for that?
Ok, looking into the color issue I downloaded the lion.svg and found that not only is the color right when using the svg.exe that Doodle created (renamed to home.svg to work with the program) but I now understand what Peter was seeing that I was missing with the sizing (when being resized in svg it was changing sizes where I hadn't realized that it should have been in Moz but now that I see what it should have been doing I see what I was missing in Peter's comments).
This is probably going to be a RGB BGR issue. We have found those in other places.

Look for a Windows only path some where that should be OS/2 as well.
I just didn't have the time to work any more on this, but for the color issue the patch in attachment 193361 [details] [diff] [review] contains a line to use gfxIFormats::BGR_A8 instead of gfxIFormats::RGB_A8 for OS/2 which took care for the 1.8 branch. I recall that there were a few changes regarding color structures on the trunk a month or so ago but the change should be similar.

I will hopefully have some time this weekend to look into the Cairo issue again and get it built on the trunk as well...
Yeah, if I had read the patches closer I would have seen that before posting.  I applied what you have to the Trunk and it fixed the issue with SVG but color issue still in Canvas.  I also applied:
+#elif defined(XP_OS2)
+  nsDrawingSurfaceOS2 *surface;
+  HPS mHPS = NULLHANDLE;
+  ctx->GetDrawingSurface((nsIDrawingSurface**)&surface);
+  if (surface) {
+    surface->GetDimensions(&mWidth, &mHeight);
+    printf("mWidth=%d, mHeight=%d\n", mWidth, mHeight);
+    mHPS = surface->GetPS();
+    if (mHPS) {
+      printf("mHPS=%lx\n", mHPS);
+      cairoSurf = cairo_os2_surface_create(mHPS, mWidth, mHeight);
+    }
+  }
+  //WinReleasePS(mHPS)

Which caused the background to become black right around the svg image.
I don't know if you got the note from Doodle but it will be changing from using HPS to HWND which might take care of that and the sizing issues.
Attached file nsIDrawingSurfaceOS2.h (obsolete) — 
Mike, here is the nsiDrawingSurfaceOS2.h that you said you thought we needed but it seems redundant to me.  I built layout with it and am about to rebuild to see if there is any difference between using it and just directly using nsDrawingSurfaceOS2.h but I don't see how there will be. 
BTW, I tried to update the comments to match our usage but they may not be quite right.  The other OS's just copied the windows comments.
Comment on attachment 201887 [details]
nsIDrawingSurfaceOS2.h

When I compiled this, I had some of Peter's patches commented out.  When I put them back in it failed.  On further inspection I see that the only people using nsidrawingsurface rather than nsdrawingsurface is MAC.  I see what needs to be added to get Peter's stuff to  work but they are not NSIMETHOD which everyone else's nsidrawingsurface only has stuff marked as.  This one is probably using the wrong set as I used the offscreen section and I probably should have used the onscreen section.  It is not needed for here anyway.
Attachment #201887 - Attachment is obsolete: true
Andy, thanks for your help. But I am currently working on improving matters with Doodle's new Cairo version. With his help I have made some progress and I think that I understand a bit better what is going on. Give me a few days to make more tests (some things seem to work better on 1.8 than on trunk and with different ways of addressing the area to paint) and confer with Doodle a bit more about the possible change from HPS to HWND before I upload a new patch.
Comment on attachment 201887 [details]
nsIDrawingSurfaceOS2.h

I think Mike suggested to create an nsIDrawingSurfaceOS2.h to be able to use the OS/2 specific functions NS2PM_ININ, NS2PM_INEX, PM2NS_ININ, and NS2PM     outside the OS/2 specific bits of the code. They would have to be included here, but...

...I don't think any more that this will be necessary. The mWidth and mHeight values returned by GetDimensions() in my patch are OK for the surface that is used. The dimensions do not change for every small resize of the browser window but seem to be allocated in bigger chunks so that I only see changes if I make the window very large or very small. (Although I have to admit that I haven't yet seen the code where this is actually done, should be somewhere in nsDrawingSurfaceOS2.*.)
Attachment #201887 - Attachment description: nsiDrawingSurfaceOS2.h → nsIDrawingSurfaceOS2.h
(In reply to comment #2)
> The problem is that as far as I understand we would
> have to release that presentation handle (at the moment called mHPS) somewhere.

I found out (with help from Doodle) that it is not necessary to release the HPS because GetPS() does not allocate it. Instead it seems that one HPS is allocated in nsOffscreenSurface::Init on startup and released on shutdown, and this one gets used. What I don't understand is how this one HPS is used to address SVG content in different tabs and windows but it seems to work somehow.

> when running my Cairo-SVG enabled build I noticed that for every redraw (like when I
> resize the window while looking at
> http://www.croczilla.com/svg/samples/lion/lion.svg>) several MB of RAM are
> allocated until shared (?) RAM is exhausted and Mozilla just dies.

I don't know where this came from but it no longer seems to happen.


(In reply to comment #20)
> Which caused the background to become black right around the svg image.

Doodle said that in his cairo 1.0.2 he hasn't implemented all the changes that went into the official cairo 1.0.2. This is where this might come from. Also note, that the Mozilla trunk is now using cairo 1.1.1 (obviously from CVS) which has no counterpart on OS/2 yet, so I am again using the 1.8 branch for now, but even there I get black backgrounds that do not redraw properly.

> I don't know if you got the note from Doodle but it will be changing from using
> HPS to HWND which might take care of that and the sizing issues.

With his help I tried various ways to make use of the window handle and a presentation handle derived from that, the code for nsSVGCairoCanvas.cpp::Init looks like this:

#if defined(XP_OS2)
  nsDeviceContextOS2 *ctx2;
  ctx->GetDeviceContext((nsIDeviceContext *&)ctx2);
  if (ctx2) {
    HWND hwnd = (HWND) (ctx2->mWidget);
    SWP swp;
    mHPS = WinGetPS(hwnd);
#ifdef DEBUG_pmw
    printf("hwnd=%lx, mHPS=%lx,  ", hwnd, mHPS);
#endif
    WinQueryWindowPos(hwnd, &swp);
    mWidth = swp.cx;
    mHeight = swp.cy;
#ifdef DEBUG_pmw
    printf("swp=%ld/%ld\n", swp.cx, swp.cy);
#endif
    if (mHPS) {
      cairoSurf = cairo_os2_surface_create(mHPS, mWidth, mHeight);
#ifdef OS2_HWND_METHOD
      cairo_os2_surface_set_HWND(cairoSurf, hwnd);
#endif
    }
  }

(mHPS would then be a private variable of the class nsSVGCairoCanvas, initialized to NULLHANDLE in the constructor and WinReleasePS()ed in the destructor). Although this code gives valid handles, they cannot be used in practice to draw anything. Don't know why, if somebody has a suggestion why this doesn't work...


Another point I am worried about is that some SVG files display (nearly) properly when loaded from the web while the same file loaded from the local disk does not display at all. And example of this behavior is <http://www.croczilla.com/svg/samples/xbl-shapes2/xbl-shapes2.xml>.

Finally, I am also embarrassed to say that I am testing with svgtetris on croczilla all the time but I am only getting worse at it... :-(
I was wrong before, there is no difference between content loaded from the web and from the disk. I had saved the files but the names were not correct...
Attached patch Updated patch (obsolete) — — Splinter Review 
OK, to show some progress here comes a new patch, made against the 1.8 branch. There isn't really much new, but now I test for the display device (is there an easier way to do that from the HPS instead of having to get the HDC as well?) before creating the cairo surface, so that the browser does not crash any more when printing a page with SVG content.

In addition to this patch one needs the files cairo-os2.h, cairo-os2-private.h, cairo-os2-surface.c of Doodle's cairo port from ftp.netlabs.org and the ZIP package and setup as explained in comment 3. Especially the last bit I don't like at all, would be great if the browser could still start without the two extra DLLs present...
Attachment #193359 - Attachment is obsolete: true
Attachment #193361 - Attachment is obsolete: true
Blocks: 320304
OK, here's the status: SVG and canvas both work on OS/2 with this patch and the three files from the Netlabs cairo distribution. Mike, what do you think would be required to get this into trunk at least? Do you see any problem that it would confuse your non-cairo builds? I really have no idea who to ask for sr.

Some notes:

- For non-builders this can be tested with my PmW-Fx 1.5 release.

- This patch only differs from the one from November by two XP_OS2 #ifdefs in mozilla/content/ to make canvas colors work.

- Some canvases display upside down, for now I only found this to happen with the tab preview extension for Firefox (similar to the feature from bug 315207). I didn't manage to debug it and my calls to the newsgroups went unanswered. I am open for hints...

- There is a deadlock between Mozilla, cairo and the OS/2 port of cairo. Mozilla only syncs with cairo releases or CVS but the OS/2 port cannot get into cairo because of calling convention problems. (Doodle created macros to circumvent this problem but the cairo maintainers don't want to add those macros to their code.) So, how can we proceed?

- To distribute Mozilla one needs to find a way to make cairo-ft-font.c dynamically load fontcfg.dll at runtime otherwise Mozilla won't start if it's not present. Not really the "responsibility" of Mozilla-OS/2 or this patch.

- The current cairo OS/2 version still has the deficiency that it doesn't take into account the background behind the cairo canvas. Again, this is not our responsibility, I hope Doodle finds the time to look at that soon. For now a hackish patch to work around this in Mozilla is 

   cairo_clip(mCR);
   cairo_new_path(mCR);
+#ifdef XP_OS2
+  cairo_set_source_rgb(mCR, 1, 1, 1);
+  cairo_rectangle(mCR,
+                  dirtyRect.x, dirtyRect.y, dirtyRect.width, dirtyRect.height);
+  cairo_fill(mCR);
+#endif

   return NS_OK;
 #endif // !MOZ_ENABLE_CAIRO_GFX
 }

 nsresult
 NS_NewSVGCairoCanvas(nsISVGRendererCanvas **result,
Attachment #202031 - Attachment is obsolete: true
Attachment #205913 - Flags: review?(mozilla)
As to the deadlock... part of the changes that Doodle made are already available in the Mozilla tree, cairo_public is what Doodle called CAIROEXPORT.  What is missing from that part is CAIROCALL and we might be able to get that added to the tree as it wouldn't hurt anyone else and would add an extra capability to it.  Even without it I think we are OK any way.  His standalone cairo.dll would not work with Mozilla without them (IOW if we built with --enable-system-cairo) but if we build in tree which is what this patch is for it creates a mozcairo.dll I believe (I generally build static so I don't recall specifically the dll name).  As this won't conflict with Doodle's cairo.dll it really doesn't need the CAIROCALL as it will use the default calling convention which will work fine in Mozilla.  
I have defined cairo_public the same in my tree as Doodle did with CAIROEXPORT such that it is already setup for declspec.
Looking ahead I think we should probably open a new bug for adding Thebes support rather than using this bug.
So are any of the cairo patches in this patch in the cairo tree?

Or will we lose them the next time mozilla syncs with cairo?
Mike: No, I specifically left out the three OS/2 cairo files in gfx/cairo/cairo. Perhaps I would need to remove the patch for gfx/cairo/cairo/src/cairo-features.h.in, too.

Andy: I thought there was agreement that only Unix can build --enable-system-xxx? Interesting to see cairo_public in the tree. Are you in contact with the cairo people and can convince them to do the rest, too? And include the OS/2 bits in their tree? Yes, Thebes would be the next step, let's file a new bug once we got these bits in.
I have built with --enable-system-cairo so it can be done on OS/2 (since Doodle made the changes for calling convention anyway).  I asked in #developers about some of the issues I was having and found that they do not like --enable-system-cairo and the impression I got was that the option might be removed entirely.  
I had been of the impression that Mozilla added the cairo_public code but I just checked on #cairo and found that it is indeed on the base code.  I can ask again if we can get the other but I was online when Doodle was asking them and it didn't seem likely.  They did add the cairo_public though which I wouldn't have expected.
OK, in the last patch there needs to be added one line in NSSVGCairoCanvas.cpp
+    surface->GetDimensions(&mWidth, &mHeight);
+    cairoSurf = cairo_os2_surface_create(hps, mWidth, mHeight);
+  }
to
+    surface->GetDimensions(&mWidth, &mHeight);
+    cairoSurf = cairo_os2_surface_create(hps, mWidth, mHeight);
+    cairo_surface_mark_dirty (cairoSurf);
+  }
It makes all the difference here.  
I pulled the Cairo CVS and zipped it up for Doodle and I have patches off of the CVS now from him.
He has changed the CAIROCALL to cairo_call to match what was done with cairo_public.  The build I am currently using was built from the cairo119.dll that he built from the CVS using --enable-system-cairo (as I understand it Mozilla is going to be syncing to the latest CVS soon).  I just did about as well as I have ever done with the SVG Tetris (up to this point I had been getting worse with each attempt it seemed).
Yes, that extra line helps, but as I understood from a discussion with tor in npm.layout there should be a different way (we should not have to use another call that other platforms don't have). I contacted Doodle about it but didn't get any reply yet.

I also found that one of the croczilla samples does not work right any more. I cannot get the the site at the moment to check the URL but it was the sample with a picture of a nuclear power station in the back and three semi-transparent movable triangles in the front. These triangles don't show up any more...
all platforms support cairo_surface_mark_dirty... but I don't think it should be needed directly after surface creation. I'd call this a bug in the OS/2 surface code.
I asked Doodle on IRC about why we were needing to call cairo_surface_mark_dirty after surface creation and below is his respons:

ok, here is the quick answer then: The OS/2 code uses a backbuffer to do what it does, because the GPI does not support alpha stuffs. Now, it means that when somebody creates a new surface, the whole window content has to be copied to the backbuffer first.
now, this copy should be put into the cairo_os2_surface_create() code, so
you wouldn't have to call mark_dirty explicitly after surface creation. However, if somebody wants to create a new surface and wants to draw all the stuffs himself,
all this "copy back from window" stuff is not needed, so why waste resources? That's why I left out this from cairo_os2_surface_create(), and
that's why a mark_dirty() is needed in OS/2. If everybody wants, I can put it into surface creation, it's not hard to do.

I don't see that we need to have it added myself but Doodle will add it if it needs to be done.
Comment on attachment 205913 [details] [diff] [review]
Updated patch, also correct colors of canvas

note: bug 323551 might have bitrotted this patch a bit

while I'm here:
+ifeq ($(MOZ_WIDGET_TOOLKIT),os2)
+SHARED_LIBRARY_LIBS += $(FREETYPE2)/lib/freetype.lib \
+                       $(FONTCONFIG2)/lib/fontcfg.lib \
+                       $(NULL)
+endif

might a better way to do this be adding the two libs to MOZ_CAIRO_LIBS in configure? (or, CAIRO_FT_LIBS that I added)
Thanks for the heads up. I will change this patch to take into account the color changes from the BeOS patch. Yes, CAIRO_FT_LIBS and also CAIRO_FT_CFLAGS are more elegant than this construct.
Attached patch Updated patch — — Splinter Review 
Updated my last cairo patch for OS/2 to
- contain no cairo stuff directly any more (I hope that we will get the stuff in gfx/cairo/cairo/src into CVS on the cairo route)
- not mess with the Makefile.ins too much, but use configure.in instead
- use cairo_surface_mark_dirty() to clean the new cairoSurf
- take into account BeOS changes (bitrot update)
  (biesi: I wonder why you don't need more XP_BEOS in nsSVGCairoCanvas?)
Attachment #205913 - Attachment is obsolete: true
Attachment #209286 - Flags: superreview?(mozilla)
Attachment #209286 - Flags: review?(benjamin)
Attachment #205913 - Flags: review?(mozilla)
Attachment #193772 - Attachment is obsolete: true
(In reply to comment #39)
>   (biesi: I wonder why you don't need more XP_BEOS in nsSVGCairoCanvas?)

Oh I do, I just missed them, your patch made me realize I needed them :) thanks for that.
(I've since filed bug 324260)
Comment on attachment 209286 [details] [diff] [review]
Updated patch

I don't get OS2_SURFACE_FEATURE... it doesn't appear to be used anywhere. Did you miss cairo-features.h.in in your diff?
Yes, it's missing intentionally. Mike requested a Mozilla-tree only patch, because we still need to get OS/2 cairo stuff upstream. That will include the OS2 addition(s) to cairo-features.h.in (mainly one line "#define @OS2_SURFACE_FEATURE@"). In the meantime one needs to take the four files cairo-features.h.in, cairo-os2.h, cairo-os2-private.h, and cairo-os2-surface.c from the OS/2 port (ftp://ftp.netlabs.org/pub/Cairo/cairo-1.0.2-os2-src.zip).
I am working on Cairo from the cvs to get a full patch to submit upstream.  I have been working on xulrunner though and haven't completed all the pieces yet.
Attachment #209286 - Flags: review?(benjamin) → review+
Comment on attachment 209286 [details] [diff] [review]
Updated patch

sr=mkaply (OS/2 only)
Attachment #209286 - Flags: superreview?(mozilla) → superreview+
oh, I wanted to respond to this comment too...

(In reply to comment #36)
> ok, here is the quick answer then: The OS/2 code uses a backbuffer to do what
> it does, because the GPI does not support alpha stuffs. Now, it means that when
> somebody creates a new surface, the whole window content has to be copied to
> the backbuffer first.

So, I don't see why the copy has to happen at surface creation time. In fact, why is there a backbuffer at all? The BeOS backend that I wrote only reads the surface data for acquire_{source,dest}_image. The other operations use native drawing methods.

Hm... but, if no native alpha blending is possible, then maybe most functions need emulation... but stuff like line drawing or filling rects could still get by without that, if they have an opaque color...
I talked to Doodle about acquire_{source,dest}_image at some point but it seems that if there is alpha blending involved it gets horribly slow, and you will get just more instances of bug 167884 (which basically means that some sites you just can't visit on OS/2 because it hangs the browser for up to minutes). mark_dirty may not be the best way to do it but the only efficient one on OS/2.
ah... ok.
Last patch checked in.
OK, thanks Mike. The Mozilla part is then fixed. Yay!

biesi: are you thinking about porting your BeOS patch to 1.8? If so we could try the same for this one.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Version: 1.8 Branch → Trunk
I'm not sure yet... I want to figure out something with freetype/fontconfig before that.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: