Hi Emmanuele,
apps using X11 to draw directly should stop doing that, because this is not 1997 any more, and we have better drawing API.
Many many apps need a faster drawing API than Cairo in order to do high frame rate animations. Interactive games is the most popular example.
I have an unusual app that requires faster drawing without animations. It's the difference between being able to use the app for some purposes or not, that is to say it's the difference between working and not working. So Cairo is just not usable in this case, it's far to slow. Why should I care that libX11 is old?
This is not a small set of users that need this. People don't care that the code is old, so long as it works for what we are doing. Please consider that Cairo is too slow for many applications. The largest group of apps that require fast drawing are openGL apps, but there is also a somewhat smaller group of apps that need faster 2-D drawing too. Cairo does not meet many minimum speed requirements. I hear that GtkGLArea is coming of age. I hope that I can use it for 2-D drawing too, but I will be sticking with libX11 drawing if that is faster than OpenGL for my use case, and I expect that drawing with libX11 will be faster for my use case. (see below for more verbose with real runnable examples)
I got two responses from my query. I attach more below. I forgot to CC the list in the email I sent before this one.
cheers
lance
I'm not sure where this is going but I need to make sure I'm clearly understood. Sorry for being too verbose. If you respond, please read it all.
1. on Cairo speed: I've spent many days testing Cairo for speed. Cairo draws lines very slowly compared to libX11 XDrawLines(). It does lots of nice things, but sometimes you just need to draw as fast as possible. In the current app I'm developing I can't even use XDrawLines(). I use XDrawPoints() with my own line drawing code, and I use my own anti-aliasing code for some of the lines.
2. The GtkGLArea <https://developer.gnome.org/gtk3/unstable/GtkGLArea.html> is news to me. I will look into it. Currently I'd like to use it to draw with libX11 and not directly with openGL given I'm just doing 2-D drawing with just point drawing. It's a little unclear what the fastest simple 2-D pixel drawing method is, because I see the X-server may be doing the right things already for fast 2-D drawing, i.e. I see it's using shared memory to get my pixels from my program, it links with OpenGL libs, and etc. Sounds like way way more than I need, and it's likely to slow things down, compared to what I have now. I'm also looking into libXrender, but know almost nothing about it yet.
3. If you'd like to understand my perspective about drawing speed I have an example that explains it well when using a GNU/Linux system. Install quickplot (available on debian apt-get install quickplot) and run `quickplot LARGESOUNDFILE' where LARGESOUNDFILE is about a 3 minute sound file. You will see quickplot display the whole sound file in about 3 seconds. Running `quickplot -c LARGESOUNDFILE' takes about 15 seconds to display. That is because the '-c' option makes quickplot use Cairo to draw. Of course back when I wrote quickplot using GTK+3.0 the difference was much more dramatic. This may be a stupid example, but it makes my point, Cairo is slow.
4. Now I'm making a software oscilloscope and 2-D drawing speed is paramount. I see that in the GTK+3.0 code that there is Cairo code in gtk_widget_send_expose() that is adding system resource waste with gdk_cairo_create(), which I don't need, given I'm drawing with libX11 and not Cairo. This is not so bad, for this scope, given that most of the time the GTK+ "draw" event and its callbacks are not used in most of my draw display frames (just used in initial draws). My code just draws over the X11 window without using GTK events, at like, for example, 60 times a second. This seems like a nasty hack. Clearly if GTK+3.0 has a method to add animations I do not want to use it, given that it will do a bunch of Cairo stuff that I'll just want to work around it order to get the speed that I need.
5. Optional: If you got this far. You can see for yourself what I'm up too and why GTK+3.0 needs to support fast 2-D drawing:
sudo apt-get install libsndfile-dev && # the prerequisite you may not have \
mkdir -p ${HOME}/tmp_quickscope && \
cd ${HOME}/tmp_quickscope && \
git clone https://github.com/lanceman2/quickscope.git && \
cd ${HOME}/tmp_quickscope/quickscope && \
./bootstrap && \
./configure --enable-debug --enable-tests --prefix ${HOME}/tmp_quickscope && \
make -j3 && ./tests/alsaCapture
I just successfully cut and pasted and ran that on my debian system, but you may not have all the prerequisites, also edit for other systems. Key <q> to quit, <m> for menu.
That will read and display sound that is coming into your microphone. There are simpler non-ALSA examples that are in the tests that you can see with a simple launcher using `./tests/tests_launcher' . If this works you'll be the first person, other then myself, to run this code.
Please let we know if you try to run that. I'll also try not to break the code with a new commit.
--lance
On 11/26/2014 02:00 PM, Emmanuele Bassi wrote:
hi;
On 26 November 2014 at 18:40, Lance Arsenault <lance arsenault gmail com> wrote:
Hello GTK developer,you can still call that function, but it's really not portable.
I've read the latest docs, looked at the latest (git) GTK+3 code, and
searched the archives, and found not direct answer to this question:
1. Is there a method, that is not deprecated, that can give the effect of
gtk_widget_set_double_buffered() for GTK3?
There are a lot of apps that must use the underlying/native drawing APIsapps using X11 to draw directly should stop doing that, because this
like libX11 and OpenGL to draw to a X11 window that is within a GTK+3.0 app.
is not 1997 any more, and we have better drawing API.
as for GL, you're lucky: GTK+ 3.16 will have OpenGL support by
default, out of the box.
ciao,
Emmanuele.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list