[cairo] Code compiled under MinGW with no error ans warring does not work.
bottom at mail.ru
Mon Jul 15 10:25:26 PDT 2013
Hi, Jonas and Olaf!
That's it! Problem has solved! Thanks a lot for paying heed to my question. Your messages helped me both _formulate_ and _solve_ the problem. For me it was the door to the usage of cairo with GTK2 in the proper way.
However I'd like to note that these two operators, given in Jonas' message (and ideas that are behind them), unfortunately, are too far from tutorials and books for beginners :-)
By the way, after Jonas' message I found another source that is - in line with  - quite valuable for the topic too - . Taking GTK3 source code as an example, it is not trivial for beginners to come to a conclusion implying that opening a cairo-context in 'expose_event' call-back function (even for the first drawing) would be a good idea. This practice isn't being used in GTK3 or, as far as I know, in GTK1.2 tutorials, neither. Within mentioned libraries a standard context (which is usually applicable for the first drawing) is being formed automatically. GTK2 do create a context too, but for GTK-wraps... Well within this picture the requirement of creating a cairo-context manually in GTK2 looks quite logical (and now - for me too ;-). But this logic has come with 'a little help of others' and a week of drudgery :-)
Researcher, MIPT, Dolgoprudniy of Moscow region.
Воскресенье, 14 июля 2013, 16:38 +02:00 от Jonas Kulla <nyocurio at gmail.com>:
>2013/7/14 Sergey K. < bottom at mail.ru >
>>thank you for your kind response! Yes, IMHO the problem is not in the SSE2 support. It must be simpler, I suppose. Because I'm not a programmer as it is, I'm just a physicist using a plain C and a very beginner in cairo and GTK. So everything indicated that I failed to find a right tutorial :-))). I'll return to this idea below. What is more, serious problems (I still trust gcc and therefore hope so) must invoke any compiler or run-time error message. However in my case - and this is quite strange - there is no any error or even warning from a compiler and the executable opening the main window only stops then in total silence too. So I have no string to pull in order to unravel the whole ball. Using GDB in ad-hoc manner in a hope to find at least something interesting is the only way to go. But it is a bit boring, you know :)
>>Following this way I have found that, as expected, there is simply no 'draw' event. And this is turned to be normally for GTK2 as it has 'expose_event' only. I found out it in . In addition user zerohour posted in  on Mon Jun 11, 2012 6:52 am: "Drawing with Cairo using GTK3 is significantly different than with GTK2.x. The GDK drawing API has been removed. So most of the tutorials on the net will not work with GTK3." Well, I during these days I have learned how much water has flown under the bridge since then. I mean many tutorials have been redrawn to date and are compliant now with GTK3, where the GDK drawing API is really eliminated and almost totally replaced with cairo API. Code from www.zetcode.com which was cited in the previous message is an example. I got in contact with Jan Bodner, the author of the code and he confirmed that it was fully rewritten (recently) to be compliant with GTK3. I wonder why he was rewriting instead of adding. Another problem that adds oil to the fire is that there are a lot of resources on the Internet without an explicit declaration of GTK+ version used. Just GTK+ code with no regard to its compatibility. So it consumes quite long time to check if they work under GTK 2.0. Taking into account these facts (significant changes in GTK and a kind of mishmash in the Internet tutorials) it looks that the solution of my simple problem will take fortune without a clever hint from experts in the field. That is why I'm here.
>>Talking in get-to-the-point terms:
>>I use the standard latest GTK+ bindings for Win32 . It is of version 2.24.10 and depended on cairo 1.10.2. You see, the version is too close to 2.22 (mentioned below as a turning point of GTK+ Drawing API) to be absolutely sure, yet 'higher than' to save the hope that code with cairo operators (instead of their wraps like gdk_draw_line(), gdk_draw_point(), etc. described in ) will work. As I see it, 2.24 is a kind of transitional version that has GDK Drawing API and 'new GTK3-cairo' (to say so) API. So one can use both deprecated GDK operators and new cairo operators with it . The former was totally eliminated from GDK3 then.
>>I didn't try older versions because they, obviously, provide less hope of using cairo operators instead of their GDK wraps. (I see that 'draw'-event was replaced with 'expose_event' (or returned - I'm not sure, but it might have been in GTK1.2) sometime after version 2.22 of GDK  and from the same version the support of the 'native cairo notation' instead of GDK wraps begins.)
>>And I didn't try newer libraries as they are not ported to Win32, as far as I know, and so they are not suitable for cross-platform programming.
>>What did I try? I have replaced 'draw' event with 'expose_event' in the cited code from zetacode.com , so the cairo operators became accessible in the process flow (initially and after deleting or position-size changes of overlapping windows). But they (cairo operators are in the call-back function fro 'expose_event') do not work anyway.
>>I started using deprecated GDK wraps  and everything went without saying. But the question is still on the scene. How can I get over to recommended operators instead of deprecated GDK wraps working within GTK 2.24.10 and cairo 1.10.2 (and GDK-PIXBUF 2.24.0)? I suppose there must be a fine thing like two-three lines of code or data types definitions that must be added to the code compliant with GTK3 to make it workable with GTK2.24... I try to take the code from www.zetcode.com as a start point. It is fully adapted to GTK3. So I'm looking for ideas (or a code snippet) on how to run it with a crossplatform library (As I wrote I suppose it is GTK 2.24.10). But I failed to find them so far and therefore went back to a deprecated but well documented GTK2 practice implying the use of GDK operators .
>>As far as C language is concerned, I think that it is a good option for us because we are developing an application for a small mobile radar keeping in mind an embedded controllers (with a usual lack of resources). Now we use notebooks been used for these purposes. Therefore an efficient application is welcomed. I know nothing from Pyton and so can't evaluate the efficacy of its code. The problem which compels us to think about a crossplatform application is that our ADC (analog to digital convertor) supplier developed a driver for Win32 only (more precise their driver for Linux doesn't work) and therefore we should take into account the possibility of working on Win32 if we failed to develop our own driver for Linux in the future. I the latter have been accomplished to date, no one would have think about Windows :)
>>Researcher, MIPT, Dolgoprudniy of Moscow region.
>>1. http:// www.gtkforums.com/./viewtopic.php?p=195286#p195286
>>2. https://developer.gnome.org/gdk/unstable/gdk-Drawing-Primitives.html#gdk-draw-line (you can use the word 'stable' instead of 'unstable' in this URL with the same result)
>>>Since nobody else replied so far...
>>>My first thought was, that Pixman was compiled for SSE2-only-mode
>>>(without support for MMX), since that was, where I encountered
>>>problems on some older hardware (CPUs, which didn't support SSE2) -
>>>but that was then easily fixed by enabling MMX in the Pixman-compile.
>>>But then, the CPU on your older Dell-Notebook does support SSE2 AFAIK.
>>>Since you run on Windows - not sure what cairo-version you use
>>>in conjunction with GTK2... meaning, whether this is the "official
>>>binaries, all belonging together and downloaded from a single site"
>>>or if it is a kind of your own mix - with parts compiled yourself...
>>>Anyways (depending on some cairo-versions) there *were* some
>>>bugs in the binding to Win32-typed-Surfaces with regards to
>>>clipping, which in the meantime are solved as I see it - though
>>>not sure, what surfacetype a GTK2-application would apply whilst
>>>creating widget-surfaces and their internal bindings to GTK-windows.
>>>If it is "plain InMemory-ImageSurfaces" GTK is using against hWnds,
>>>then I don't see what could go wrong with some simple drawings -
>>>I'd have understood "missing Font-render-output", since this has
>>>a larger potential to fail due to some more dependencies in the
>>>GTK-stack - but "simple moveto, lineto demos"... <shrug>
>>>Did you tried downloading and installing other GTK2-packages for
>>>windows? A bit more recent - or alternatively a bit older ones -
>>>just to see if the problems are related to a certain release?
>>>Also not sure how important it is for you, to use GTK2 as the
>>>"cairo-provider" (so to say) - and if the C-language is a must on
>>>your end ... I mean, there's also cairo-bindings for Python or LUA
>>>(incl. download-packages for the win-platform), which you could try-out.
>>>Perhaps the cairo-wrappers those tools come with, produce "something
>>>visiblefor a change"... well, you could even use plain VBScript (*.vbs)
>>>in the meantime, to produce cairo-renderings or cairo-Widget-based Mini-
>>>Applications, if that is, what you planned to use cairo for...
>>>So, yeah - just poking a bit, if your problem is still there -
>>>or what you tried with regards to different GTK-versions - or with
>>>regards to "entirely different cairo-based frameworks/languages".
>>>cairo mailing list
>>>cairo at cairographics.org
>>cairo mailing list
>>cairo at cairographics.org
>you don't have to use GDK drawing primitives under GTK2,
>there are cairo compatibility functions  specifically for this case.
>Eg., in an 'expose-event' callback for a widget you'd like to draw to,
>you would call:
> cairo_t *cr = gdk_cairo_create(widget->window);
> /* ... Do your usual cairo drawing ... */
>and that's it! =)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cairo