Cairo backend
Some of you may have noticed that this week the release 1.0 of cairo has been published. For quite some time GNUstep has had a backend based on this graphics library. But this has always been incomplete and also cairo has changed a lot over the months. In the last few weeks I cleaned up the code for this backend and extended it a bit. Basically it is now ready to try it, although many features are still missing. Known limitations: - fonts are still hard coded - text in NSTextView sometimes doesn't get displayed - images are often displayed incorrect - copying from one GState to another uses wrong transformation - some minor operations are missing or untested I hope to solve these problems within the next month and will make a public announcment for the cairo backend after that. If you find other bugs, feel free to report them, or even better help to resolve them. If you want to compile the cairo backend, use the command: ./configure --enable-graphics=cairo --disable-glitz We probably should switch glitz off by default, as this is not offically supported by cairo at the moment Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Win32 Cairo backend...
Hi!
Selon Fred Kiefer <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] schrieb:
> > I've started to work on the win32 Cairo backend (winlib and glitz)
(...)
>
(...)
> Just to warn you: I plan to do a big rework of the GNUstep cairo
> backend, in the hope to get scrolling to work. If you have any changes
> to the backend yourself, feel free to forward them to me.
>
> Cheers,
> Fred
There is a far better patch than the one i posted some days ago :
http://amstradstuff.free.fr/GNUstep/back-070105.patch.gz
(based upon rev 24314)
New files :
http://amstradstuff.free.fr/GNUstep/back-070105.new.tar.gz
to be expanded in base/trunk
- Changes in config system seem to be ok : you should take it !
tested on mingw and linux/debian
with xlib, winlib, cairo and glitz-cairo backend
configure is not included
- Little change in */cairo, but some new files :
Source/cairo/CairoSurface.m manages Win32*Surface classes
(compile time... need some re-writting ?)
*/cairo/Win32Cairo* files dont really work :
i get some windows, then some cairo "out of memory" error messages.
Cant move or resize a window (out of memory).
I dont understand...
*/cairo/Win32GlitzCairo* files dont work at all !
but glitz is also broken under x11 (?)
If these could help... :-)
Regards
Xavier
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cairo backend
On 8/28/05, Fred Kiefer <[EMAIL PROTECTED]> wrote: > Some of you may have noticed that this week the release 1.0 of cairo has > been published. For quite some time GNUstep has had a backend based on > this graphics library. But this has always been incomplete and also > cairo has changed a lot over the months. In the last few weeks I cleaned > up the code for this backend and extended it a bit. Basically it is now > ready to try it, although many features are still missing. Wow, excellent news ! > Known limitations: > - fonts are still hard coded > - text in NSTextView sometimes doesn't get displayed > - images are often displayed incorrect > - copying from one GState to another uses wrong transformation > - some minor operations are missing or untested > > I hope to solve these problems within the next month and will make a > public announcment for the cairo backend after that. If you find other > bugs, feel free to report them, or even better help to resolve them. I'll try to install cairo and test that :-) thanks, -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cairo backend
Nicolas Roard wrote: > On 8/28/05, Fred Kiefer <[EMAIL PROTECTED]> wrote: >>Some of you may have noticed that this week the release 1.0 of cairo has >>been published. For quite some time GNUstep has had a backend based on >>this graphics library. But this has always been incomplete and also >>cairo has changed a lot over the months. In the last few weeks I cleaned >>up the code for this backend and extended it a bit. Basically it is now >>ready to try it, although many features are still missing. > > Wow, excellent news ! > >>Known limitations: >>- fonts are still hard coded >>- text in NSTextView sometimes doesn't get displayed >>- images are often displayed incorrect >>- copying from one GState to another uses wrong transformation >>- some minor operations are missing or untested >> >>I hope to solve these problems within the next month and will make a >>public announcment for the cairo backend after that. If you find other >>bugs, feel free to report them, or even better help to resolve them. > > I'll try to install cairo and test that :-) > I did forget to mention that you have to hack the cairo library for now. The GNUstep backend uses some cairo functions that are not exported by cairo. These are: _cairo_toy_font_face_create _cairo_scaled_font_text_to_glyphs What I did to get cairo to export these functions was to redefine cairo_private in cairoint.h to be empty. I will set up a mail to the cairo maintainer and ask for a better solution. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Win32 Cairo backend...
> to be expanded in base/trunk ERRATUM : to be expanded in back/trunk :-\ Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Win32 Cairo backend : strange behavior...
Hello I've started to work on the win32 Cairo backend (winlib and glitz) I get prety (almost) black windows : Calculator and Gorm start and run :-) Well... when i'm lucky... In fact i need to insert some NSLog in my code _to_avoid_Gorm_crash_ !! These NSLog have to be at the right place, or Calculator fails to create windows (Cairo-glitz only - Cairo-winlib seems to be ok (but with black windows)) Any suggestions ? Thanks !! Last question : is the X11 (glitz) Cairo backend usable ? Thks. Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Win32 Cairo backend : strange behavior...
Xavier wrote: > In fact i need to insert some NSLog in my code to avoid Gorm > crash !! > These NSLog have to be at the right place, or Calculator fails > to > create windows did you try to run your app in gdb? setting a break point on [NSException raise] helps usually. Backtrace is also a helpful tool. dave -- _ _ _(_)(_)_ David Wetzel, Turbocat's Development, (_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG, _/ \_ Fax +49 33056 82835 Phone +49 33056 82834 (__) http://www.turbocat.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Win32 Cairo backend : strange behavior...
[EMAIL PROTECTED] schrieb: > I've started to work on the win32 Cairo backend (winlib and glitz) > I get prety (almost) black windows : Calculator and Gorm start and run :-) > > Well... when i'm lucky... > > In fact i need to insert some NSLog in my code _to_avoid_Gorm_crash_ !! > These NSLog have to be at the right place, or Calculator fails to > create windows > > (Cairo-glitz only - Cairo-winlib seems to be ok (but with black windows)) > > Any suggestions ? Thanks !! > > Last question : is the X11 (glitz) Cairo backend usable ? Thks. > Not sure if anybody ever did use this. For me glitz is not working, as my glitz release seems to be too old. Just to warn you: I plan to do a big rework of the GNUstep cairo backend, in the hope to get scrolling to work. If you have any changes to the backend yourself, feel free to forward them to me. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Win32 Cairo backend : strange behavior...
Selon David Wetzel <[EMAIL PROTECTED]>: > Xavier wrote: > > > In fact i need to insert some NSLog in my code to avoid Gorm > > crash !! > > These NSLog have to be at the right place, or Calculator fails > > to > > create windows > > did you try to run your app in gdb? > setting a break point on [NSException raise] helps usually. > Backtrace is also a helpful tool. > > dave I didn't try to run Gorm in gdb because sometimes it runs fine ! An other weird behavior : if i uncomment an other NSLog (always in the same Win32CairoGlitzSurface method) i get a glitz error 'couldn't find ARGB32 surface format' (glitz_find_standard_format) _before_ the execution of the new NSLog (but at the 2nd invocation of the method). I dont understand how a std output can corrupt a program or change the result of an opengl(glitz) call. IMHO the reason of all this is either : - a gcc 4.1 bug - a mingw bug - a video driver bug - a wrong library configuration - a thread conflict - another weird thing i cant understand Here is a try with gdb in a case where Gorm cant start and ends with 'couldn't find ARGB32 surface format' (exit 1). See a full backtrace below - i dont understand anything :o\ The call came from ntdll.dll, from atioglxx.dll, from libglitz-1.exe, from ntdll.dll, from atioglxx.dll, from -[NSTableView highlightSelectionInClipRect:] But first gdb gives a warning : warning: HEAP[Gorm.exe]: warning: Invalid Address specified to RtlReAllocateHeap( 003D, 014C53A0 ) My gdb seems buggy :-\ I see a call to 'ntdll!RtlFreeThreadActivationContextStack' Could it be a thread conflict error ? Gorm GSBackend is default to 'GlitzCairo-012', that's the name of my backend. But each time i launch Gorm, i get : 'Did not find correct version of backend, falling back to std.' I dont know what that means. Could it be the reason ? Same message with Calculator or GFractal examples (the last is very very sloowww) Any ideas ? Thanks :-) Xavier - Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c911231 in ntdll!DbgUiConnectToDbg () from ntdll.dll warning: HEAP[Gorm.exe]: warning: Invalid Address specified to RtlReAllocateHeap( 003D, 014C53A0 ) bt #0 0x7c911231 in ntdll!DbgUiConnectToDbg () from ntdll.dll #1 0x7c97c943 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #2 0x0022f4bc in ?? () #3 0x7c97cd80 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #4 0x014c5398 in ?? () #5 0x003d in ?? () #6 0x014c53a0 in ?? () #7 0x0022f558 in ?? () #8 0x7c97da4e in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #9 0x003d in ?? () #10 0x014c5398 in ?? () #11 0x7c97dd74 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #12 0x003d in ?? () #13 0x014c53a0 in ?? () #14 0x4060 in ?? () #15 0x0c3f5fd0 in ?? () #16 0x003d in ?? () #17 0x002c in ?? () #18 0x0009 in ?? () #19 0x0022f520 in ?? () #20 0x7c97cde9 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #21 0x003d in ?? () #22 0x in ?? () from #23 0x0c6240c8 in ?? () #24 0x003d in ?? () #25 0x0c624090 in ?? () #26 0x0022f5a8 in ?? () #27 0x7c91ee18 in strchr () from ntdll.dll #28 0x7c927bb8 in ntdll!RtlRealPredecessor () from ntdll.dll #29 0x in ?? () from #30 0x003d in ?? () #31 0x in ?? () from #32 0x04a0 in ?? () #33 0x003d in ?? () #34 0x003d0608 in ?? () #35 0x7c97dd25 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #36 0x014c5398 in ?? () #37 0x0c624090 in ?? () #38 0x in ?? () from #39 0x0169 in ?? () #40 0x0022f4d0 in ?? () #41 0x7c9206eb in ntdll!RtlAppendStringToString () from ntdll.dll #42 0x0022f730 in ?? () #43 0x7c91ee18 in strchr () from ntdll.dll #44 0x7c97dd48 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #45 0x0001 in ?? () #46 0x0022f740 in ?? () #47 0x7c95c651 in ntdll!RtlInsertElementGenericTableAvl () from ntdll.dll #48 0x003d in ?? () #49 0x5161 in ?? () #50 0x014c53a0 in ?? () #51 0x0488 in ?? () #52 0x in ?? () from #53 0x014c53a0 in ?? () #54 0x0488 in ?? () #55 0x0022f5f0 in ?? () #56 0x0048 in ?? () #57 0x003d in ?? () #58 0x0c2e1dd0 in ?? () #59 0x0c6240c8 in ?? () #60 0x0c624088 in ?? () #61 0x0c3f in ?? () #62 0x0c624090 in ?? () #63 0x0140 in ?? () #64 0x0022f530 in ?? () #65 0x01010102 in ?? () #66 0x0022f790 in ?? () #67 0x7c91ee18 in strchr () from ntdll.dll #68 0x7c97dd48 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #69 0x in ?? () #70 0x7c97dd25 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #71 0x7c95c651 in ntdll!RtlInsertElementGenericTableAvl () from ntdll.dll #72 0x003d in ?? () #73 0x5161 in ?? () #74 0x0c624090 in ?? () #75 0x7c927bb0 in ntdll!RtlRealPredecessor () from ntdll.dll #76 0x in ?? () from #77 0x0c624090 in ?? () #78 0x0030 in ?? () #79 0x4060 in ?? () #80 0x0c40 in ?? () #81 0x0022f7dc in ?? () #82 0x in ?? () from #83 0x0c551e28 in ?? () #84 0x018f3f40 in ?? () #85 0x692c30fe in atiPPHSN () from C:\WINDOWS\system32
Re: Win32 Cairo backend : strange behavior...
Selon Fred Kiefer <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] schrieb: > > I've started to work on the win32 Cairo backend (winlib and glitz) > > I get prety (almost) black windows : Calculator and Gorm start and run :-) > > > > Well... when i'm lucky... > > > > In fact i need to insert some NSLog in my code _to_avoid_Gorm_crash_ !! > > These NSLog have to be at the right place, or Calculator fails to > > create windows > > > > (Cairo-glitz only - Cairo-winlib seems to be ok (but with black windows)) > > > > Any suggestions ? Thanks !! > > > > Last question : is the X11 (glitz) Cairo backend usable ? Thks. > > > > Not sure if anybody ever did use this. For me glitz is not working, as > my glitz release seems to be too old. > Just to warn you: I plan to do a big rework of the GNUstep cairo > backend, in the hope to get scrolling to work. If you have any changes > to the backend yourself, feel free to forward them to me. > > Cheers, > Fred You may get a patch here : http://amstradstuff.free.fr/GNUstep/back-061222.patch - Changes in config system seem to be ok : glitz-wgl and cairo over win32 configure is included but is generated from config.in - Little change in */cairo, but some new files : */cairo/Win32* files dont really work (as you know...) - A change in Tools/win32pbs.m but it might be a problem on my side. All this needs a lot of testing Regards Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Win32 Cairo backend : strange behavior...
On Dec 22, 2006, at 6:26 AM, [EMAIL PROTECTED] wrote: Selon David Wetzel <[EMAIL PROTECTED]>: Xavier wrote: I dont understand how a std output can corrupt a program or change the result of an opengl(glitz) call. IMHO the reason of all this is either : - a gcc 4.1 bug - a mingw bug - a video driver bug - a wrong library configuration - a thread conflict - another weird thing i cant understand Here is a try with gdb in a case where Gorm cant start and ends with 'couldn't find ARGB32 surface format' (exit 1). See a full backtrace below - i dont understand anything :o\ The call came from ntdll.dll, from atioglxx.dll, from libglitz-1.exe, from ntdll.dll, from atioglxx.dll, from -[NSTableView highlightSelectionInClipRect:] But first gdb gives a warning : warning: HEAP[Gorm.exe]: warning: Invalid Address specified to RtlReAllocateHeap ( 003D, 014C53A0 ) My gdb seems buggy :-\ This seems more like a memory error that is corrupting the heap or the stack. Also, possibly a header conflict (two conflicting headers for the same library). I see a call to 'ntdll!RtlFreeThreadActivationContextStack' Could it be a thread conflict error ? Gorm GSBackend is default to 'GlitzCairo-012', that's the name of my backend. But each time i launch Gorm, i get : 'Did not find correct version of backend, falling back to std.' I dont know what that means. Could it be the reason ? Same message with Calculator or GFractal examples (the last is very very sloowww) You need to set the GSBackend name to just 'GlitzCairo'. The gui searches for the matching version number by appending the gui version number to the GSBackend name. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Win32 Cairo backend : strange behavior...
Hello You are so right !! :-) I had to install the svn version of base and gui. No more crash :-) I dont understand why my backend was compile against the svn gui (012), not the installed gui (010)... Thanks ! I'm now working on these black windows... Xavier Selon Adam Fedor <[EMAIL PROTECTED]>: > Also, possibly a header conflict (two conflicting headers > for the same library). (...) > > You need to set the GSBackend name to just 'GlitzCairo'. The gui > searches for the matching version number by appending the gui version > number to the GSBackend name. > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Compiler warnings for the cairo backend
Hi Nicola, starting with your changes to the GNUstep make system, I am now getting loads of warnings when compiling the cairo backend: Compiling file CairoSurface.m ... gcc: -lXft: linker input file unused because linking not done gcc: -lXrender: linker input file unused because linking not done gcc: -lX11: linker input file unused because linking not done gcc: -lfontconfig: linker input file unused because linking not done gcc: -lexpat: linker input file unused because linking not done gcc: -lfreetype: linker input file unused because linking not done gcc: -lz: linker input file unused because linking not done Looks like linker flags get passed on to the compilation step, where they aren't needed. I have attached the config.log file to make it easier for you the track this problem, if you don't have cairo installed. Cheers, Fred This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure --enable-graphics=cairo --with-name=cairo -disable-glitz ## - ## ## Platform. ## ## - ## hostname = hugo uname -m = i686 uname -r = 2.6.18.2-34-default uname -s = Linux uname -v = #1 SMP Mon Nov 27 11:46:27 UTC 2006 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /root/GNUstep/Tools PATH: /usr/GNUstep/Local/Tools PATH: /usr/GNUstep/System/Tools PATH: /home/fred/GNUstep/Tools PATH: /usr/GNUstep/Local/Tools PATH: /usr/GNUstep/System/Tools PATH: /home/fred/bin PATH: /usr/local/bin PATH: /usr/bin PATH: /sbin PATH: /usr/X11R6/bin PATH: /usr/sbin PATH: /bin PATH: /usr/games PATH: /opt/gnome/bin PATH: /opt/kde3/bin PATH: /usr/lib/jvm/jre/bin PATH: /usr/lib/mit/bin PATH: /usr/lib/mit/sbin PATH: /usr/lib/qt3/bin ## --- ## ## Core tests. ## ## --- ## configure:1402: checking for gcc configure:1418: found /usr/bin/gcc configure:1428: result: gcc configure:1672: checking for C compiler version configure:1675: gcc --version &5 gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:1678: $? = 0 configure:1680: gcc -v &5 Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) configure:1683: $? = 0 configure:1685: gcc -V &5 gcc: '-V' option must have argument configure:1688: $? = 1 configure:1711: checking for C compiler default output file name configure:1714: gccconftest.c >&5 configure:1717: $? = 0 configure:1763: result: a.out configure:1768: checking whether the C compiler works configure:1774: ./a.out configure:1777: $? = 0 configure:1794: result: yes configure:1801: checking whether we are cross compiling configure:1803: result: no configure:1806: checking for suffix of executables configure:1808: gcc -o conftestconftest.c >&5 configure:1811: $? = 0 configure:1836: result: configure:1842: checking for suffix of object files configure:1863: gcc -c conftest.c >&5 configure:1866: $? = 0 configure:1888: result: o configure:1892: checking whether we are using the GNU C compiler configure:1916: gcc -c conftest.c >&5 configure:1922: $? = 0 configure:1926: test -z || test ! -s conftest.err configure:1929: $? = 0 configure:1932: test -s conftest.o configure:1935: $? = 0 configure:1948: result: yes configure:1954: checking whether gcc accepts -g configure:1975: gcc -c -g conftest.c >&5 configure:1981: $? = 0 configure:1985: test -z || test ! -s conftest.err configure:1988: $? = 0 configure:1991: test -s conftest.o configure:1994: $? = 0 configure:2005: result: yes configure:2022: checking for gcc option to accept ANSI C configure:2092: gcc -c -g -O2 conftest.c >&5 configure:2098: $? = 0 configure:2102: test -z || test ! -s conftest.err configure:2105: $? = 0 configure:2108: test -s conftest.o configure:2111
RE: Compiler warnings for the cairo backend
Not sure this has much to do with my changes, it looked more like a typo in configure.ac whereby XFT_LIBS was added to CAIRO_CFLAGS instead of CAIRO_LIBS, resulting in -- GRAPHIC_CFLAGS=-I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -lXft -lXrender -lfontconfig -lfreetype -lX11 which obviously would (at least) generate compile warnings. Anyway, I fixed it on trunk. Please give it a go. :-) Thanks -Original Message- From: Fred Kiefer <[EMAIL PROTECTED]> Sent: Tue, February 27, 2007 12:17 pm To: Nicola Pero <[EMAIL PROTECTED]>, GNUstep Developer Subject: Compiler warnings for the cairo backend Hi Nicola, starting with your changes to the GNUstep make system, I am now getting loads of warnings when compiling the cairo backend: Compiling file CairoSurface.m ... gcc: -lXft: linker input file unused because linking not done gcc: -lXrender: linker input file unused because linking not done gcc: -lX11: linker input file unused because linking not done gcc: -lfontconfig: linker input file unused because linking not done gcc: -lexpat: linker input file unused because linking not done gcc: -lfreetype: linker input file unused because linking not done gcc: -lz: linker input file unused because linking not done Looks like linker flags get passed on to the compilation step, where they aren't needed. I have attached the config.log file to make it easier for you the track this problem, if you don't have cairo installed. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compiler warnings for the cairo backend
Thank you, works perfectly now! Fred Nicola Pero schrieb: > Not sure this has much to do with my changes, it looked more like a typo > in configure.ac whereby XFT_LIBS was added to CAIRO_CFLAGS instead > of CAIRO_LIBS, resulting in -- > > GRAPHIC_CFLAGS=-I/usr/include/cairo -I/usr/include/freetype2 > -I/usr/include/libpng12 -I/usr/include/cairo -I/usr/include/freetype2 > -I/usr/include/libpng12 -lXft > -lXrender -lfontconfig -lfreetype -lX11 > > which obviously would (at least) generate compile warnings. Anyway, I fixed > it on trunk. > Please give it a go. :-) > > Thanks > > > -Original Message- > From: Fred Kiefer <[EMAIL PROTECTED]> > Sent: Tue, February 27, 2007 12:17 pm > To: Nicola Pero <[EMAIL PROTECTED]>, GNUstep Developer > Subject: Compiler warnings for the cairo backend > > Hi Nicola, > > starting with your changes to the GNUstep make system, I am now getting > loads of warnings when compiling the cairo backend: > > Compiling file CairoSurface.m ... > gcc: -lXft: linker input file unused because linking not done > gcc: -lXrender: linker input file unused because linking not done > gcc: -lX11: linker input file unused because linking not done > gcc: -lfontconfig: linker input file unused because linking not done > gcc: -lexpat: linker input file unused because linking not done > gcc: -lfreetype: linker input file unused because linking not done > gcc: -lz: linker input file unused because linking not done > > Looks like linker flags get passed on to the compilation step, where > they aren't needed. I have attached the config.log file to make it > easier for you the track this problem, if you don't have cairo installed. > > Cheers, > Fred > ___ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Unable to use cairo backend on MinGW
I installed cairo backend on MinGW using cairo 1.14.0. All the methods in +initializeBackend are executed, but I don't see anything. Any idea about in which method can I look? Thanks. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Cairo backend: factored out fontconfig code, testing needed
Hi all, After a while (and Fred's well-timed prod), after a time-wasting summer camp, after getting over nasty headaches and cold, I've decided to (for now) give up on looking at avoiding having an OpalGState class. It seems to me that it'll be easier to query Opal for its state when appropriate, and have OpalGState do the right thing when -copyWIthZone: is called. (Again, this is the original approach and multiple times suggested by Fred, who is not to be doubted :-)) I still believe that long-term Opal and the Opal-based backend should be able to cooperate enough to avoid implementing GState in the backend as a class. But, for now, since Fred kindly pointed out to me (a long time ago) that GState means quite a different thing in AppKit than it does in Core Graphics (for example, I was unaware it can be copied, that the GState stacks can be switched independently of the context, etc) -- it makes little sense to use the little remaining time for playing with this when any work required to implement this quickly has to be done anyway in trunk, and can later be somewhat reused. So to do something that'll be useful, I've first managed to figure out what's the minimum that needs to be implemented for the layout system to even pick up on information returned by -advancementForGlyph:, and size menu items accordingly in the Opal backend. Happy with that, I moved on to doing the next necessary thing to get fonts do the right thing in Opal backend: figuring out the fonts on the system, et al. In order to make this code shared with Cairo, I moved it to separate classes in "fontconfig/" directory. These are now base classes for Cairo backend's CairoFaceInfo, CairoFontInfo and CairoFontEnumerator. Since this means I messed with a big, core part of GNUstep that's in active use, please test my changes in revision 37066 and yell at me accordingly. My testing involved starting SystemPreferences and clicking around. Then I started Ink and played with the fonts panel. I did not see issues, which is why the code is now in trunk of gnustep-back. -- Ivan Vučica i...@vucica.net - http://ivan.vucica.net/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Cairo backend seems broken - mainScreen visibleFrame has no size
Hi, I just upgraded back and now no app is able to display images and/or sizinig windows. I think there is an issue determining the size and/or resolution of the screen. For example, LaternaMagica comes up with an infinte main window. I fear it might be related to the latest enhancements of Sergey, but have to investigate. Can anyone else reproduce? I get these warnings: (moria:gap/user-apps/LaternaMagica) multix% LaternaMagica 2020-01-30 07:31:38.889 LaternaMagica[17860:17860] No local time zone specified. 2020-01-30 07:31:38.889 LaternaMagica[17860:17860] Using time zone with absolute offset 0. 2020-01-30 07:31:38.888 LaternaMagica[17860:17860] styleoffsets ... guessing offsets 2020-01-30 07:31:38.935 LaternaMagica[17860:17860] styleoffsets ... guessing offsets 2020-01-30 07:31:39.144 LaternaMagica[17860:17860] The font specified for NSFont, FreeSans, can't be found. 2020-01-30 07:31:39.446 LaternaMagica[17860:17860] The font specified for NSFont, FreeSans, can't be found. 2020-01-30 07:31:39.477 LaternaMagica[17860:17860] The font specified for NSFont, FreeSans, can't be found. 2020-01-30 07:31:39.492 LaternaMagica[17860:17860] The font specified for NSFont, FreeSans, can't be found. 2020-01-30 07:31:39.764 LaternaMagica[17860:17860] File NSView.m: 1183. In -[NSView setFrame:] given negative width 2020-01-30 07:31:39.764 LaternaMagica[17860:17860] File NSView.m: 1183. In -[NSView setFrame:] given negative width 2020-01-30 07:31:39.765 LaternaMagica[17860:17860] File NSView.m: 1183. In -[NSView setFrame:] given negative width 2020-01-30 07:31:39.765 LaternaMagica[17860:17860] File NSView.m: 1188. In -[NSView setFrame:] given negative height 2020-01-30 07:31:39.767 LaternaMagica[17860:17860] Cairo status 'invalid value (typically too big) for the size of the input (surface, pattern, etc.)' in DPSinitgraphics PRICE, instead, comes up, shows the same warnings as before in the conosole. Additionally, when loading an image: 2020-01-30 07:36:44.420 PRICE[17955:17955] current screen size: 0.00 x 0.00 2020-01-30 07:36:44.420 PRICE[17955:17955] current window size: 118.00 x 28.00 2020-01-30 07:36:44.745 PRICE[17955:17955] Cairo status 'invalid value (typically too big) for the size of the input (surface, pattern, etc.)' in DPSinitgraphics So this tells me that: screenFrameSize = [[NSScreen mainScreen] visibleFrame].size; NSLog(@"current screen size: %f x %f", screenFrameSize.width, screenFrameSize.height); is 0! and this can't be good! Riccardo
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi Riccardo, On Thu, Jan 30, 2020 at 9:35 AM Riccardo Mottola wrote: > Hi, > > I just upgraded back and now no app is able to display images and/or > sizinig windows. > > I think there is an issue determining the size and/or resolution of the > screen. For example, LaternaMagica comes up with an infinte main window. > > I fear it might be related to the latest enhancements of Sergey, but > have to investigate. Can anyone else reproduce? > > I get these warnings: > (moria:gap/user-apps/LaternaMagica) multix% LaternaMagica > 2020-01-30 07:31:38.889 LaternaMagica[17860:17860] No local time zone > specified. > 2020-01-30 07:31:38.889 LaternaMagica[17860:17860] Using time zone with > absolute offset 0. > 2020-01-30 07:31:38.888 LaternaMagica[17860:17860] styleoffsets ... > guessing offsets > 2020-01-30 07:31:38.935 LaternaMagica[17860:17860] styleoffsets ... > guessing offsets > 2020-01-30 07:31:39.144 LaternaMagica[17860:17860] The font specified > for NSFont, FreeSans, can't be found. > 2020-01-30 07:31:39.446 LaternaMagica[17860:17860] The font specified > for NSFont, FreeSans, can't be found. > 2020-01-30 07:31:39.477 LaternaMagica[17860:17860] The font specified > for NSFont, FreeSans, can't be found. > 2020-01-30 07:31:39.492 LaternaMagica[17860:17860] The font specified > for NSFont, FreeSans, can't be found. > 2020-01-30 07:31:39.764 LaternaMagica[17860:17860] File NSView.m: 1183. > In -[NSView setFrame:] given negative width > 2020-01-30 07:31:39.764 LaternaMagica[17860:17860] File NSView.m: 1183. > In -[NSView setFrame:] given negative width > 2020-01-30 07:31:39.765 LaternaMagica[17860:17860] File NSView.m: 1183. > In -[NSView setFrame:] given negative width > 2020-01-30 07:31:39.765 LaternaMagica[17860:17860] File NSView.m: 1188. > In -[NSView setFrame:] given negative height > 2020-01-30 07:31:39.767 LaternaMagica[17860:17860] Cairo status 'invalid > value (typically too big) for the size of the input (surface, pattern, > etc.)' in DPSinitgraphics > > PRICE, instead, comes up, shows the same warnings as before in the > conosole. Additionally, when loading an image: > > 2020-01-30 07:36:44.420 PRICE[17955:17955] current screen size: 0.00 > x 0.00 > 2020-01-30 07:36:44.420 PRICE[17955:17955] current window size: > 118.00 x 28.00 > 2020-01-30 07:36:44.745 PRICE[17955:17955] Cairo status 'invalid value > (typically too big) for the size of the input (surface, pattern, etc.)' > in DPSinitgraphics > > So this tells me that: > screenFrameSize = [[NSScreen mainScreen] visibleFrame].size; > NSLog(@"current screen size: %f x %f", screenFrameSize.width, > screenFrameSize.height); > > is 0! and this can't be good! > > Riccardo > > Can't reproduce it. I've tried LatternaMagica 0.5 with `art` and `cairo` backends using both 'master' and `randr` branch. -- Sergii Stoian
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi! I updated my laptop (NetBSD / amd64 / gcc compiler and runtime) and now all GUI apps crash on startup: Starting program: /Local/Tools/Ink Xlib: extension "MIT-SHM" missing on display "localhost:11.0". 2020-01-31 14:58:52.354 Ink[14930:130845475800848] styleoffsets ... guessing offsets Program received signal SIGSEGV, Segmentation fault. 0x7700c986b6b7 in -[XGServer(WindowOps) boundsForScreen:] (self=0x7700d4c87010, _cmd=0x7700c9ab4150 <_OBJC_SELECTOR_TABLE+1808>, screen=0) at XGServerWindow.m:4528 4528 if (output_info->crtc) (gdb) bt #0 0x7700c986b6b7 in -[XGServer(WindowOps) boundsForScreen:] (self=0x7700d4c87010, _cmd=0x7700c9ab4150 <_OBJC_SELECTOR_TABLE+1808>, screen=0) at XGServerWindow.m:4528 #1 0x7700c98600d2 in -[XGServer(WindowOps) _OSFrameToXFrame:for:] (self=0x7700d4c87010, _cmd=0x7700c9ab4430 <_OBJC_SELECTOR_TABLE+2544>, o=..., window=0x7700d6135c80) at XGServerWindow.m:512 #2 0x7700c986423d in -[XGServer(WindowOps) window] (self=0x7700d4c87010, _cmd=0x7700c9ab4390 <_OBJC_SELECTOR_TABLE+2384>, frame=..., type=2, style=64, screen=0) at XGServerWindow.m:1917 #3 0x7700c9863498 in -[XGServer(WindowOps) _setupRootWindow] (self=0x7700d4c87010, _cmd=0x7700c9ab0030 <_OBJC_SELECTOR_TABLE+400>) at XGServerWindow.m:1614 #4 0x7700c98560fb in -[XGServer _initXContext] (self=0x7700d4c87010, _cmd=0x7700c9ab0080 <_OBJC_SELECTOR_TABLE+480>) at XGServer.m:469 #5 0x7700c9856278 in -[XGServer initWithAttributes:] (self=0x7700d4c87010, _cmd=0x7700d60b4550 <_OBJC_SELECTOR_TABLE+144>, info=0x0) at XGServer.m:487 #6 0x7700d5c2db71 in +[GSDisplayServer serverWithAttributes:] () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #7 0x7700d5a31715 in -[NSApplication _init] () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #8 0x7700d50f87d1 in -[NSObject performSelector:withObject:] () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #9 0x7700d5180760 in -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #10 0x7700d518061c in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:modes:] () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #11 0x7700d518068b in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #12 0x7700d5a31b89 in -[NSApplication init] () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #13 0x7700d5a3167e in +[NSApplication sharedApplication] () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #14 0x7700d5a11699 in NSApplicationMain () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #15 0x004019db in gnustep_base_user_main () #16 0x7700d512ac8b in main () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #17 0x004017fc in ___start () #18 0x7f7e8a60cc38 in ?? () from /usr/libexec/ld.elf_so #19 0x0001 in ?? () #20 0x7f7fffaecf48 in ?? () #21 0x in ?? () the structure is null and needs to be checked. I also noticed that in case the call fails, there is no fallback. I restructured the code a little bit and pushed a fix. At least, now it does not crash for me anymore and Ink comes up and shows windows :-) However, I sstill get issues with X: 2020-01-31 15:07:47.335 Ink[27979:125763785598736] X-Windows error - BadRROutput (invalid Output parameter) on display: localhost:11.0 type: 0 serial number: 576 request code: 138 and even windowmaker when a GS application starts. wmaker(catchXError(startup.c:118)): warning: internal X error: BadMatch (invalid parameter attributes) Request code: 12 X_ConfigureWindow Request minor code: 0 Resource ID: 0x63 Error serial: 59874 Regards, Riccardo
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi, On Fri, Jan 31, 2020 at 6:08 PM Riccardo Mottola wrote: > Hi! > > I updated my laptop (NetBSD / amd64 / gcc compiler and runtime) and now > all GUI apps crash on startup: > > > Starting program: /Local/Tools/Ink > Xlib: extension "MIT-SHM" missing on display "localhost:11.0". > 2020-01-31 14:58:52.354 Ink[14930:130845475800848] styleoffsets ... > guessing offsets > > Program received signal SIGSEGV, Segmentation fault. > 0x7700c986b6b7 in -[XGServer(WindowOps) boundsForScreen:] > (self=0x7700d4c87010, > _cmd=0x7700c9ab4150 <_OBJC_SELECTOR_TABLE+1808>, screen=0) at > XGServerWindow.m:4528 > 4528 if (output_info->crtc) > (gdb) bt > #0 0x7700c986b6b7 in -[XGServer(WindowOps) boundsForScreen:] > (self=0x7700d4c87010, > _cmd=0x7700c9ab4150 <_OBJC_SELECTOR_TABLE+1808>, screen=0) at > XGServerWindow.m:4528 > #1 0x7700c98600d2 in -[XGServer(WindowOps) _OSFrameToXFrame:for:] > (self=0x7700d4c87010, > _cmd=0x7700c9ab4430 <_OBJC_SELECTOR_TABLE+2544>, o=..., > window=0x7700d6135c80) at XGServerWindow.m:512 > #2 0x7700c986423d in -[XGServer(WindowOps) window] > (self=0x7700d4c87010, > _cmd=0x7700c9ab4390 <_OBJC_SELECTOR_TABLE+2384>, frame=..., type=2, > style=64, screen=0) at XGServerWindow.m:1917 > #3 0x7700c9863498 in -[XGServer(WindowOps) _setupRootWindow] > (self=0x7700d4c87010, > _cmd=0x7700c9ab0030 <_OBJC_SELECTOR_TABLE+400>) at > XGServerWindow.m:1614 > #4 0x7700c98560fb in -[XGServer _initXContext] > (self=0x7700d4c87010, _cmd=0x7700c9ab0080 <_OBJC_SELECTOR_TABLE+480>) > at XGServer.m:469 > #5 0x7700c9856278 in -[XGServer initWithAttributes:] > (self=0x7700d4c87010, > _cmd=0x7700d60b4550 <_OBJC_SELECTOR_TABLE+144>, info=0x0) at > XGServer.m:487 > #6 0x7700d5c2db71 in +[GSDisplayServer serverWithAttributes:] () > from /System/Library/Libraries/libgnustep-gui.so.0.28.0 > #7 0x7700d5a31715 in -[NSApplication _init] () from > /System/Library/Libraries/libgnustep-gui.so.0.28.0 > #8 0x7700d50f87d1 in -[NSObject performSelector:withObject:] () > from /System/Library/Libraries/libgnustep-base.so.1.27.0 > #9 0x7700d5180760 in -[NSObject(NSThreadPerformAdditions) > performSelector:onThread:withObject:waitUntilDone:modes:] > () from /System/Library/Libraries/libgnustep-base.so.1.27.0 > #10 0x7700d518061c in -[NSObject(NSThreadPerformAdditions) > performSelectorOnMainThread:withObject:waitUntilDone:modes:] () from > /System/Library/Libraries/libgnustep-base.so.1.27.0 > #11 0x7700d518068b in -[NSObject(NSThreadPerformAdditions) > performSelectorOnMainThread:withObject:waitUntilDone:] () > from /System/Library/Libraries/libgnustep-base.so.1.27.0 > #12 0x7700d5a31b89 in -[NSApplication init] () from > /System/Library/Libraries/libgnustep-gui.so.0.28.0 > #13 0x7700d5a3167e in +[NSApplication sharedApplication] () from > /System/Library/Libraries/libgnustep-gui.so.0.28.0 > #14 0x7700d5a11699 in NSApplicationMain () from > /System/Library/Libraries/libgnustep-gui.so.0.28.0 > #15 0x004019db in gnustep_base_user_main () > #16 0x7700d512ac8b in main () from > /System/Library/Libraries/libgnustep-base.so.1.27.0 > #17 0x004017fc in ___start () > #18 0x7f7e8a60cc38 in ?? () from /usr/libexec/ld.elf_so > #19 0x0001 in ?? () > #20 0x7f7fffaecf48 in ?? () > #21 0x in ?? () > > > the structure is null and needs to be checked. > I also noticed that in case the call fails, there is no fallback. I > restructured the code a little bit and pushed a fix. At least, now it > does not crash for me anymore and Ink comes up and shows windows :-) > > However, I sstill get issues with X: > > 2020-01-31 15:07:47.335 Ink[27979:125763785598736] X-Windows error - > BadRROutput (invalid Output parameter) >on display: localhost:11.0 > type: 0 > serial number: 576 > request code: 138 > > > and even windowmaker when a GS application starts. > > > wmaker(catchXError(startup.c:118)): warning: internal X error: BadMatch > (invalid parameter attributes) > Request code: 12 X_ConfigureWindow > Request minor code: 0 > Resource ID: 0x63 > Error serial: 59874 > > > > Regards, > Riccardo > I've added check for number of XRandR outputs. Please test and report if it helps. Out of curiosity, do you have XRandR enabled and it's not working? What is the Xorg log messages about it? P.S.: You haven't answer me about my XInitThreads idea. Have you succeded? -- Sergii Stoian
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi Sergii! Sergii Stoian wrote: I've added check for number of XRandR outputs. Please test and report if it helps. Yes it helps! now applications start both locally and remotely I got only one kind of error now and only once a the first start of Ink. starting it again, no error, so I do wonder and will keep an eye on it and also test on other computers. wmaker(catchXError(startup.c:118)): warning: internal X error: BadMatch (invalid parameter attributes) Request code: 12 X_ConfigureWindow Request minor code: 0 Resource ID: 0x63 Error serial: 59874 no more X-Windows errors. Out of curiosity, do you have XRandR enabled and it's not working? What is the Xorg log messages about it? How can I know? xome option to the "xrandr" command? P.S.: You haven't answer me about my XInitThreads idea. Have you succeded? Sorry, had no time to test yet. "Real Job" is consuming 99% of CPU time :-P But will test that as soonas I can and report back. Riccardo
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi Riccardo! On Sat, Feb 1, 2020 at 6:28 PM Riccardo Mottola wrote: > Hi Sergii! > > Sergii Stoian wrote: > > I've added check for number of XRandR outputs. Please test and report > > if it helps. > > Yes it helps! now applications start both locally and remotely > > I got only one kind of error now and only once a the first start of Ink. > starting it again, no error, so I do wonder and will keep an eye on it > and also test on other computers. > Good. I've done testing myself and found more flows in current implementation. I start working on solution and almost done. You can find more fixes in 'randr' branch of libs-back. > wmaker(catchXError(startup.c:118)): warning: internal X error: BadMatch > (invalid parameter attributes) > Request code: 12 X_ConfigureWindow > Request minor code: 0 > Resource ID: 0x63 > Error serial: 59874 > > no more X-Windows errors. > > > Out of curiosity, do you have XRandR enabled and it's not working? > > What is the Xorg log messages about it? > > How can I know? xome option to the "xrandr" command? > Do you observe some good "xrandr" output? > > P.S.: You haven't answer me about my XInitThreads idea. Have you > succeded? > > Sorry, had no time to test yet. "Real Job" is consuming 99% of CPU time > :-P But will test that as soonas I can and report back. > OK, no problem. Riccardo > -- Sergii Stoian
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi! On 2/1/20 11:32 PM, Sergii Stoian wrote: Yes it helps! now applications start both locally and remotely I got only one kind of error now and only once a the first start of Ink. starting it again, no error, so I do wonder and will keep an eye on it and also test on other computers. Good. I've done testing myself and found more flows in current implementation. I start working on solution and almost done. You can find more fixes in 'randr' branch of libs-back. I fear the latest changes made window opening slower, I tested also on good and up-to-date computers with fine video card. no more X-Windows errors. > Out of curiosity, do you have XRandR enabled and it's not working? > What is the Xorg log messages about it? How can I know? xome option to the "xrandr" command? Do you observe some good "xrandr" output? in the sense that it reports correct screen size? then yes. It is true both for local as remote displays. Riccardo
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi, > On Feb 2, 2020, at 17:44, Riccardo Mottola wrote: > > Hi! > > On 2/1/20 11:32 PM, Sergii Stoian wrote: >> >> Yes it helps! now applications start both locally and remotely >> >> I got only one kind of error now and only once a the first start of Ink. >> starting it again, no error, so I do wonder and will keep an eye on it >> and also test on other computers. >> >> Good. I've done testing myself and found more flows in current >> implementation. >> I start working on solution and almost done. You can find more fixes in >> 'randr' branch of libs-back. > > I fear the latest changes made window opening slower, I tested also on good > and up-to-date computers with fine video card. > What do you mean by “opening slower”? Timeout between user action (click, key equivalent press) and window appearing? Window is drawn slowly on first appear? >> >> no more X-Windows errors. >> >> > Out of curiosity, do you have XRandR enabled and it's not working? >> > What is the Xorg log messages about it? >> >> How can I know? xome option to the "xrandr" command? >> >> Do you observe some good "xrandr" output? > > in the sense that it reports correct screen size? then yes. > > It is true both for local as remote displays. > As I already wrote - I know what the cause of a problem. I’ve almost completed new implementation. Please wait for commits in ‘randr’ branch. > Riccardo > Sergii
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi Riccardo, On Sun, Feb 2, 2020 at 11:18 PM Sergii Stoian wrote: > Hi, > > On Feb 2, 2020, at 17:44, Riccardo Mottola > wrote: > > Hi! > On 2/1/20 11:32 PM, Sergii Stoian wrote: > > >> Yes it helps! now applications start both locally and remotely >> >> I got only one kind of error now and only once a the first start of Ink. >> starting it again, no error, so I do wonder and will keep an eye on it >> and also test on other computers. >> > > Good. I've done testing myself and found more flows in current > implementation. > I start working on solution and almost done. You can find more fixes in > 'randr' branch of libs-back. > > > I fear the latest changes made window opening slower, I tested also on > good and up-to-date computers with fine video card. > > What do you mean by “opening slower”? Timeout between user action (click, > key equivalent press) and window appearing? > Window is drawn slowly on first appear? > No further explanation needed. Yesterday I've faced the same problem and fixed that. > > >> no more X-Windows errors. >> >> > Out of curiosity, do you have XRandR enabled and it's not working? >> > What is the Xorg log messages about it? >> >> How can I know? xome option to the "xrandr" command? >> > > Do you observe some good "xrandr" output? > > > in the sense that it reports correct screen size? then yes. > > It is true both for local as remote displays. > > As I already wrote - I know what the cause of a problem. I’ve almost > completed new implementation. > Please wait for commits in ‘randr’ branch. > > Riccardo > > I've found cause of a problem and fixed that. Could you please try te lastest code in `randr` branch? -- Sergii Stoian
Re: [bug #28590] Cairo backend displays wrong colors on X server with a different endianness
[from bug-gnustep] On Wed, Jan 20, 2010 at 02:47:38PM +, Fred Kiefer wrote: > > And we only need to change any code in the case where we > don't use shared memory (this is for some reason broken on modern X Servers > and I don't have a clue). Broken how? Note that shared pixmaps are an optional part of MIT-SHM support, and that recent Xorg servers have it disabled by default. I see that the XWindowBuffer.m code tries to use shared XImages and shared Pixmaps, and hence if shared pixmaps are disabled, disables all X shm support. i.e. this bit: if (!XShmQueryVersion(display, &major, &minor, &pixmaps) || !pixmaps) Could the code be usefully restructured to use shared Ximages without the need for shared pixmaps? Since it only seems to be used for the window background, possibly so by adjusting the above to ignore the chared pixmap support, and removing the line that tries to create the shared pixmap. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [bug #28590] Cairo backend displays wrong colors on X server with a different endianness
Am 20.01.2010 20:52, schrieb Derek Fawcus: > [from bug-gnustep] > > On Wed, Jan 20, 2010 at 02:47:38PM +, Fred Kiefer wrote: >> >> And we only need to change any code in the case where we >> don't use shared memory (this is for some reason broken on modern X Servers >> and I don't have a clue). > > Broken how? Note that shared pixmaps are an optional part of MIT-SHM support, > and that recent Xorg servers have it disabled by default. > > I see that the XWindowBuffer.m code tries to use shared XImages and shared > Pixmaps, and hence if shared pixmaps are disabled, disables all X shm > support. i.e. this bit: > > if (!XShmQueryVersion(display, &major, &minor, &pixmaps) || !pixmaps) > > Could the code be usefully restructured to use shared Ximages without > the need for shared pixmaps? Since it only seems to be used for the > window background, possibly so by adjusting the above to ignore > the chared pixmap support, and removing the line that tries to create > the shared pixmap. I just committed some code changes that try to follow your advice. Could you please have a look. Thank you Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [bug #28590] Cairo backend displays wrong colors on X server with a different endianness
On Fri, Jan 22, 2010 at 06:20:05PM +0100, Fred Kiefer wrote: > > I just committed some code changes that try to follow your advice. Could > you please have a look. Yeah - that looks like what I had in mind. The question then arises as to what now happens during the resulting exposes that this pixmap was supposed to optimise the handling of. /phx ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [bug #28590] Cairo backend displays wrong colors on X server with a different endianness
On Mon, Jan 25, 2010 at 07:41:36AM -0800, Derek Fawcus wrote:
>
> Yeah - that looks like what I had in mind.
BTW - you should probably change the following error message:
if (!XShmQueryVersion(display, &major, &minor, &use_xshm_pixmaps))
{
NSLog(@"XShm pixmaps not supported by X server.");
and I suspect you can remove the previous call to XShmQueryExtension().
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
