Index
> Linux > Fastest and very "assembly" way to draw in Linux.Goto page 1, 2, 3 Next |
| Author |
|
|
JohnFound 07 Feb 2015, 20:46
Shame on me, I found this method only recently, but was surprised how fast it is and how comfortable is to use it in Linux.
It is MIT-SHM extension of X server. The idea is to create XImage with memory shared with the X server. This way, there is no need to transfer all the image data to the server and drawing the images to the screen is very fast. On my slow netbook the drawing speed raises at least twice to 200fps. You can read more about this API here: http://www.x.org/releases/current/doc/xextproto/shm.html Here is some example code: http://www.mesa3d.org/brianp/xshm.c and in Linux simply use: "man xshm" for quick reference. Anyway, I made some simple example that uses this method in FreshLib test programs (branch FreshLibGUI): /freshlib/test_code0/TestPNG.asm (it is actually test of the PNG library, but I added some animation code in order to test the framerate...) Anyway, if you don't want to download the source and compile, I will attach the precompiled binary for Linux. If you have some problems with the program, please report it. Also you can report the frame rate you got on your machine.
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 Last edited by JohnFound on 08 Feb 2015, 07:57; edited 1 time in total |
|||||||||||
07 Feb 2015, 20:46 |
|
|
HaHaAnonymous 07 Feb 2015, 22:57
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 17:58; edited 1 time in total |
|||
|
07 Feb 2015, 22:57 |
|
|
JohnFound 08 Feb 2015, 07:22
sleepsleep wrote: 1300+ FPS, running on CPU0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz It is known bug that the test application crashes on the end of the animation, i.e. after 100000 frames. On 1300+ fps, it should happen after 56 seconds or little bit less. If it happens earlier, it is another unknown bug that need to be researched.  _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
|
08 Feb 2015, 07:22 |
|
|
JohnFound 08 Feb 2015, 07:58
BTW, mentioned bug is fixed and I updated the attachment.
|
|||
|
08 Feb 2015, 07:58 |
|
|
HaHaAnonymous 15 Feb 2015, 01:19
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 17:57; edited 1 time in total |
|||
|
15 Feb 2015, 01:19 |
|
|
JohnFound 15 Feb 2015, 07:26
HaHaAnonymous wrote: I got rid of my Intel IGP and I am now getting 900+ FPS. How slow is my pure little netbook!  
HaHaAnonymous wrote: CPU usage: MAX! CPU can be 100% loaded only if it has two or less cores - one for the test program and one for the X server. _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
|
15 Feb 2015, 07:26 |
|
|
HaHaAnonymous 15 Feb 2015, 12:08
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 17:56; edited 1 time in total |
|||
|
15 Feb 2015, 12:08 |
|
|
JohnFound 15 Feb 2015, 13:29
I think we are talking about the same. The demo program above has one thread and is intentionally designed to run at maximal possible CPU use in order to test the maximal framerate. (which is 50% on CPU with two cores). But, there is some synchronization code that can lower the main thread CPU utilization.
This is because after drawing the flame and calling XShmImageDraw, the main thread must wait for the X server to complete the drawing process, before drawing the next frame. On my 2 core AMD CPU, the program itself loads the CPU by 26% (which means that it waits approximately the half of the time) and the X server process loads the CPU by 48%. And one interesting observation: The Windows version of the same program, when run in WINE has similar flamerate, but loads the CPU differently: The main thread has 50% CPU and the X server only 26..27%; |
|||
|
15 Feb 2015, 13:29 |
|
|
gens 15 Feb 2015, 19:15
under a compositing window manager and plenty of cores, i get
X ~64% program ~36% kwin (window manager) ~6% it says it's over 1100 fps il try it under a non-compositing wm later also cool stuff, thx here's another low level graphics things i found http://betteros.org/tut/graphics1.php |
|||
|
15 Feb 2015, 19:15 |
|
|
JohnFound 16 Feb 2015, 06:24
@gens, thanks for the link. It is interesting reading.
|
|||
|
16 Feb 2015, 06:24 |
|
|
keantoken 31 Dec 2015, 19:15
I got 850-1100FPS, generally around 1000FPS on an AMD FX8320 (4GHz 8 core). This program apparently tests single-thread performance.
Button 1 only works the first time I start the program. If I press button 1 after button 2 has been running, sections of the animation don't get drawn or are flashing. Maybe if this method doesn't require esoteric secret knowledge I will be able to use it. |
|||
|
31 Dec 2015, 19:15 |
|
|
Matrix 28 Jan 2016, 19:33
Hi John!
This is something similar to the already existing DirectFB and Linux Framebuffer https://en.wikipedia.org/wiki/DirectFB https://en.wikipedia.org/wiki/Linux_framebuffer (I am working on XCB right now. but only because it is more readily available) btw found a little something for you 
framebuffer square test on linux: http://www.cubieforums.com/index.php?topic=33.0 https://gist.github.com/FredEckert/3425429 Low Level Graphics on Linux http://betteros.org/tut/graphics1.php just open a console that has fbdev and magic |
|||
|
28 Jan 2016, 19:33 |
|
|
kerr 25 Feb 2016, 06:14
Oh yeah! Thank you for you methond!
|
|||
|
25 Feb 2016, 06:14 |
|
|
revolution 24 Dec 2018, 01:39
I've made this topic sticky.
|
|||
|
24 Dec 2018, 01:39 |
|
|
revolution 24 Dec 2018, 08:37
I tried this on Linux Mint 18 and get the following error:
Quote: ./TestPNG: error while loading shared libraries: libXft.so.2: cannot open shared object file: No such file or directory |
|||
|
24 Dec 2018, 08:37 |
|
|
JohnFound 24 Dec 2018, 08:52
revolution wrote: I tried this on Linux Mint 18 and get the following error: Just check what "libXft.so*" you have and create a symlink named "libXft.so.2" to it. For example on my system I have: Code: $ll /lib/libXft.so* lrwxrwxrwx 1 root root 15 юни 7 2018 /lib/libXft.so -> libXft.so.2.3.2 lrwxrwxrwx 1 root root 15 юни 7 2018 /lib/libXft.so.2 -> libXft.so.2.3.2 -rwxr-xr-x 1 root root 88024 юни 7 2018 /lib/libXft.so.2.3.2 _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
|
24 Dec 2018, 08:52 |
|
|
revolution 24 Dec 2018, 09:25
Apparently there are no versions of libXft in the Mint system:
Code: ~ ll /lib/libXft.so* ls: cannot access '/lib/libXft.so*': No such file or directory ~ find /lib* -iname "*xft*" ~ Code: ~ sudo apt-get install libXft [sudo] password for revolution: Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libXft |
|||
|
24 Dec 2018, 09:25 |
|
|
JohnFound 24 Dec 2018, 10:55
I am not very sure, but isn't it "libxft2" in Mint?
|
|||
|
24 Dec 2018, 10:55 |
|
|
revolution 24 Dec 2018, 11:06
The find command doesn't think so:
Code: ~ find /lib* -iname "*xft*" ~ Edit: Doing a wider search finds: Code: ~ find / -iname "*xft*.so*" 2> /dev/null /usr/lib/x86_64-linux-gnu/libpangoxft-1.0.so.0 /usr/lib/x86_64-linux-gnu/libXft.so.2 /usr/lib/x86_64-linux-gnu/libpangoxft-1.0.so /usr/lib/x86_64-linux-gnu/libXft.so /usr/lib/x86_64-linux-gnu/libpangoxft-1.0.so.0.3800.1 /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2 ~ Code: ~ file /usr/lib/x86_64-linux-gnu/libXft.so.2 /usr/lib/x86_64-linux-gnu/libXft.so.2: symbolic link to libXft.so.2.3.2 ~ file /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2 /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8c54b965325cb03a8b469662c5f88e9724a1eec7, stripped Code: ~ file TestPNG TestPNG: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, stripped |
|||
|
24 Dec 2018, 11:06 |
|
| Goto page 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|