Hey, I just built Quickscope from source, and can't find any code that draws using cairo inside it. Where is it?
On Wed, Nov 26, 2014 at 6:08 PM, Lance Arsenault <lance.arsena...@gmail.com> wrote: > 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.arsena...@gmail.com> >> wrote: >> >>> Hello GTK developer, >>> >>> 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? >>> >> you can still call that function, but it's really not portable. >> >> There are a lot of apps that must use the underlying/native drawing APIs >>> like libX11 and OpenGL to draw to a X11 window that is within a GTK+3.0 >>> app. >>> >> apps using X11 to draw directly should stop doing that, because this >> 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 > -- Jasper
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
