bugGNUstep - Bugs: bug #21200, Cairo version dependency and other...

Group
 
 

bug #21200: Cairo version dependency and other nuisances

Submitter:  Mark Tracy <tracy454>
Submitted:  Sun 30 Sep 2007 09:14:56 PM UTC
   
 
Category:  Backend Severity:  2 - Minor
Item Group:  Change Request Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 05 Oct 2007 01:59:47 PM UTC, comment #7: 

Yes, this issue was introduced into GNUstep when Nicolas Roads extended the cairo backend to use 32 bit drawing depth, when available on the computer.
This in itself is something good, as this will allow us to implement transparent window contents. But as with any new feature there were a few problems that only show up in special configurations. We need to carefully inspect each of them and find a general solution.
The change I did today looked like one to me. It may still not be sufficent, but could you please give it a try and report back on the result. And if possible, post your reply to bug #21203 :-(

Fred Kiefer <FredKiefer>
Group Member
Fri 05 Oct 2007 01:38:41 PM UTC, comment #6: 

I would just like to add that I have this same exact issue on Slackware 12.0 with cairo 1.4.10.  Seems like the problem is with a recent GNUstep change though.  Cairo backend worked for me a few weeks back (I can't say exactly when, but I think 3-4 weeks ago) perfectly, and then stopped working when I reinstalled slackware and GNUstep from scratch last week.

Stef <stefanbidi>
Group Member
Fri 05 Oct 2007 12:15:07 PM UTC, comment #5: 

You problem does not belong to this bug report, but into #21203 :-)

If you are using the latest SVN then changing the assignement in XGCairoXImageSurface may make a difference. Please try the values 24 and 32 and also report the depth that is used by X.

Did it work before my latest change?

Fred Kiefer <FredKiefer>
Group Member
Fri 05 Oct 2007 11:32:16 AM UTC, comment #4: 

I've just tried the latest svn code on my machine (both in 64bit and 32bit mode) with cairo backend (I've been using the art backend for the last few months).

I'm using debian unstable, which has libcairo2-dev version 1.4.10 and I get the out of memory errors from cairo as well as X-Windows errors: 'BadMatch  (invalid parameter attributes)'

What I see is a white square where the appicon should be, and a white rectangle where the app menu should be.


Richard Frith-Macdonald <CaS>
Group Member
Fri 05 Oct 2007 10:57:58 AM UTC, comment #3: 

The offending lines of code now get compiled conditionally. So it should again work with older versions of cairo, at least as bad as before the introduction of these calls.

Of course using the latest cairo release is still the way to go.

Fred Kiefer <FredKiefer>
Group Member
Mon 01 Oct 2007 02:39:49 AM UTC, comment #2: 

Thanks for explaining the details. I have not tried any of the intermediate versions of Cairo. I did try back-0.12 with Cairo-1.4.10 and got the same error messages.

The art backend uses nfonts and the docs tell one exactly what needs to be done to get things working. I don't advocate keeping nfonts, just some documented way of making sure that one's font setup is going to work under Cairo. Neither am I suggesting that this be solved with more code. By the way, do you know if the SystemPreferences Fonts control panel works under Cairo/Freetype? I have not been able to test it.

Mark Tracy <tracy454>
Sun 30 Sep 2007 10:43:51 PM UTC, comment #1: 

First thank you for your comments and for using the expermintal cairo backend of GNUstep.
The change to cairo 1.4 was needed to get the clipping working correctly, change on 2007-09-06 (I am not sure at which version cairo added groups, so perhaps there is another dependency). Without proper clipping this backend was useless. Of course you are right, we should check and warn about outdated version of cairo.
The problem with cairo 1.4.10 should be fixed in SVN (change on 2007-09-09), at least that was what I was told. I am using cairo 1.4.6 myself (actually on Suse 10.2 just like you). Maybe I should upgrade and test myself.

Your problem with the font names is a bit of a mystery to me. We there use the same code to provide default font names as the art backend, but setting the values in the user defaults is always a solution here.

Fred Kiefer <FredKiefer>
Group Member
Sun 30 Sep 2007 09:14:56 PM UTC, original submission:  

Sometime in the last month or so, back-0.13 (Trunk) started using API calls from Cairo-1.4 for the Cairo backend. This was not noted in the ChangeLog, nor is it checked in configure. I noticed it because Suse 10.2 provides Cairo-1.2.9.

Installing Cairo-1.4.2 at least allowed me to build and run the Cairo backend. (Doesn't work, but that is another story.)

However, when I tried Cairo-1.4.10, the current stable release, CairoGState.m copyWithZone: generated errors "Cairo status out of memory in copy path." A quick peek with valgrind didn't reveal any memory errors there.

A final nuisance is font names. Since the cairo backend uses FreeType, the selection of fonts is at the mercy of the distribution. In my case, Suse 10.2 provides dozens of fonts, none of which is named "Helvetica." There is "Adobe Helvetica." I'm not sure what to suggest, but perhaps this is best handled in the documentation. My solution was to set the appropriate defaults for NSFont and NSBoldFont.

I'm not sure what the intent is with respect to Cairo version requirements, but I thought it worth pointing out.

Mark Tracy <tracy454>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by stefanbidi (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by tracy454 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-02-26 FredKiefer Open/ClosedIn Test Closed
    2007-10-05 FredKiefer StatusNone Fixed
        Open/ClosedOpen In Test
    2007-09-30 FredKiefer CategoryNone Backend
        Severity3 - Normal 2 - Minor
        Item GroupNone Change Request
        Assigned toNone FredKiefer

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code