no gui "failed to allocate image"

Help
mesamoo
2008-01-04
2013-05-23
  • mesamoo

    mesamoo - 2008-01-04

    I'm running suse 10.3 64bit on a core2duo cpu.
    4gb ram, kde3.8 desktop, xorg 7.2 nvidia propietary drivers.
    My xorg.conf file has a couple additions to work w/ compiz though I'm not using compiz right now
    kernel 2.6.23...

    I have installed the bristol / brighton packages for 64bit from the
    packman (for suse) repo. (version 0.10.12-2pm)

    When I run any of the bristol synths
    (for example "startBristol -2600")
    I get an empty window where the synth interface should be.

    The terminal (konsole) I am running the program from reports the
    following error numerous times
            "failed to allocate image"

    I also tried the .586 rpms with the same result. Then I built the
    program myself, no errors were reported by ./configure or make but
    I still get the same error when running the program. I also tried the howto from studio64 without any improvement. All give me a blang gui

    I googled around a bit and did find a few references to this problem
    but none with a solution that worked for me.

    The packager at packman tried to rebuild w/ a possible fix but I see no change unfortunately.

    Some have mentioned that the "failed to allocate image" message might be a problem with 64bit systems and xorg but I haven't found the references myself.

    Ideas would be appreciated.

    see ya

    dh

     
    • Nick Copeland

      Nick Copeland - 2008-01-04

      Hi DH,

      Odd problem. This error message is printed by the X11 lightweight interface that links brighton, the GUI library into the windowing system. If it makes you feel better it is when the XCreateImage() call returns NULL implying no memory was allocated for the desired bitmap.

      It could well be an issue with 64bit and/or xorg however I don't have a 64bit system available to me at the moment to do any testing.

      The code section used here is the libbrightonX11 XImage acceleration stuff and you may get better results if you try with the -pixmap option at runtime. The pixmap code is 'a little' slower however it may give you more positive results as it uses a separate interface to the X Server. The library supports both interfaces, selectable as a compile time or runtime option. I believe the pixmap code has actually been tested to work on 64bit systems (in as much as one diligent user passed me a set of diffs used to make it work, and they were applied).

      Regards,

      Nick.

       
      • mesamoo

        mesamoo - 2008-01-04

        Thank you for the reply.
        The -pixmap argument does indeed seem to work and isn't terribly slow on my machine.
        Thanks for the tip.

        I look forward to learning how to use Bristol now

        Thanks again

        see ya
        dh

         
    • Nick Copeland

      Nick Copeland - 2008-01-04

      Hello Again,

      Good, very pleased about that. When I implemented the XImage accelerators I almost removed the pixmap code but decided not to in the end. At the time it was a solution to a problem I had not seen yet - now it is useful! Tjoho!

      The interface may not really be much slower, especially on your nice core duo, but on a single CPU then the response sometimes slows down when the CPU has a lot of higher priority audio processing to execute.

      I think I have a fix for the problem. You can either wait for the next upload due out over the next few weeks or I can send you the single file (or diffs) required to test the fix. This would actually help me quite a bit, being without a 64bit machine to run the app.

      Best regards,

      Nick.

       
      • mesamoo

        mesamoo - 2008-01-04

        To tell you the truth I'm not very experienced w/ using diffs, but
        I have applied kernel patches occasionally so I might be able to learn.

        I will be glad to test the modified source or the single file for you if you want to send it to me or just tell me where and when a download is available.

        See ya

        dh

         
    • Nick Copeland

      Nick Copeland - 2008-01-04

      You should have the bRender.c file now through email. No hurry with testing it - you may run into other issues.

      Good luck.

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks