|
Post by vovchik on Sept 27, 2018 23:10:37 GMT 1
Dear Peter, The Hershey widths are now perfect. Thanks and great work. And the nuklear demo works nicely, too. But the real improvement is in the regular canvas fonts. With kind regards, vovchik
|
|
|
Post by bigbass on Sept 28, 2018 7:41:25 GMT 1
Hello Peter
I am also using a rpi3 b now as my official linux box so will be able to work with that
as a note downloaded latest beta of bacon and ran your nuklear demo
compiled and ran correctly
P.S vovchik
will be able to test your demos now too (starting tomorrow) and offer feedback all went fine with just using the rasberian desktop image looking forward to get back in action with fltk too
Joe
|
|
|
Post by Pjot on Sept 28, 2018 18:01:25 GMT 1
Thanks guys! But the font rendering was not perfect yet As you may have noticed, the left aligning of the words in the "File" menu was not really straight. Also, some labels did not fit on the screen, while there is enough space. The cause for this was the scaling, because the Nuklear context scales down the font to 0.6, otherwise the text does not fit into the widgets. The Canvas wrapper will then relatively scale text around the center of that text (as designed), and this is causing the erroneous alignment. To fix this, I have added the Canvas wrapper function FONTALIGN(). By default, FONTALIGN() will leave the font alignment unchanged to be backwards compatible (argument = 0). If the argument = 1 then the alignment will stick to the left. It is used by the Nuklear drawing backend to ensure correct font alignment. Additionally, the ARC() function was improved so it really draws an arc as it is intended. The canvas-plugin-nuklear drawing backend now also makes use of this primitive, leaving just 2 Nuklear drawing actions unimplemented. All files updated. Regards Peter PS I found some more documentation about the Nuklear widgets here (still not complete)
|
|
|
Post by Pjot on Sept 29, 2018 9:06:56 GMT 1
|
|
|
Post by bigbass on Sept 29, 2018 21:12:11 GMT 1
Hello Peter on the rpi3 it compiles and runs but there is a big lag in the events to respond I haven't done any investigating into the why but it seems to be in a loop and not acting in real time to the mouse clicks or other events I am getting a long lag in the first display also whereas using fltk everythig is fast to respond so I dont believe it is a hardware problem anyway this is good progress and I know you will find the cause and fix it correctly when I have more time I will try a pure nuklear compile and see what happens to compare with the baconized demo Joe
|
|
|
Post by Pjot on Sept 30, 2018 8:58:38 GMT 1
Hi Joe,
Thanks for checking out. Your screenshot looks really good and seems to be fine!
Regarding the lag you are experiencing, I can think of two reasons:
(1) the Canvas wrapper uses OpenGL calls to draw the elements. So if your graphical driver is using software rendering (implemented by MESA for example), then the whole GUI can be very slow. Can you confirm that your Raspberry is actually using hardware (direct) rendering? You can check this as follows:
If you do not see "Yes" then there is a problem with your graphics card driver.
(2) the Canvas wrapper uses a callback mechanism, and maybe your Raspberry is already consuming a lot of CPU resources. In such case, please check if your CPU is not occupied for a 100% by some other process, or try to change the callback timer in the demo program:
CALLBACK(20, Show_Gui)
The '20' means 20 milliseconds, you can try to set it to a lower value to see if it has a positive effect.
HTH Peter
|
|
|
Post by Pjot on Oct 2, 2018 20:23:51 GMT 1
Added the 'NK_COMMAND_RECT_MULTI_COLOR' primitive in the drawing backend. It enables drawing a color picker, for example. Updated files: Regards Peter Attachments:
|
|
|
Post by bigbass on Oct 3, 2018 19:20:33 GMT 1
Hello Peter
it compiles cleanly and runs the color change still a lag in the event to take action but your suggestion lowered the lag about a second but its about 2 seconds behind
all of your work is great it just seems that a little tweaking for the events is needed for a slower cpu
keep up the good work maybe vovchik or Alex could confirm or have different results
Joe
|
|
|
Post by vovchik on Oct 3, 2018 22:18:20 GMT 1
Dear Joe and Peter,
I have the same symptoms Joe describes on PI. A little better on a slow Intel, but noticeable lag...even after changing the CALLBACK to 5 or 10.
With kind regards, vovchik
|
|
|
Post by Pjot on Oct 4, 2018 6:51:16 GMT 1
Thanks guys, It is a pity, and unfortunately I do not have a RPi to reproduce the error Can you confirm the hardware rendering? Regards, Peter
|
|
|
Post by vovchik on Oct 4, 2018 7:51:29 GMT 1
Dear Peter, I get this on PI and my slow Intel machines: glxinfo | grep "direct rendering" direct rendering: Yes
so I suppose hardware rendering is enabled. with kind regards, vovchik
|
|
|
Post by bigbass on Oct 6, 2018 6:00:07 GMT 1
Hello Peter here is a progress report of nuklear
I had time today to compile some demos in pure c and test them using the official nuklear
all of those folders compiled cleanly and generated binaries that ran correctly and quickly
---------------------------------- /home/pi/Downloads/nuklear-master/demo x11_rawfb x11_xft x11 x11_opengl2 x11_opengl3 ---------------------------------- a note the fastest events are from x11_xft
so the good news is that the raspberry pi3 does run these nuklear demos correctly without any lag
this means we might be having a problem in the porting of the code at some place where is the place ? I don't know yet but tomorrow I will test a few ideas It may be an inner or outer loop multiplying the delay or a redraw ?
it would be possible to have automated timed callback and step through it and see what is happening
the good news is it will work but we just need to find out the why there is the lag Joe
|
|
|
Post by Pjot on Oct 6, 2018 14:12:01 GMT 1
Thanks bigbass, Looking at your findings, there could be several possible causes. Let's take some steps: (1) can you try to run the Aquarium demo and see if there is a lag there as well? If so, then it is not Nuklear related. (2) the OpenGL backend used by the Canvas wrapper also can be slow. For example, on my system, the GLUT backend is way slower compared to the SDL backend. Your compiled samples clearly use another (different) backend (X11). Therefore, can you add the following line to the Nuklear demo right after the INCLUDE: INCLUDE canvas INCLUDE canvas-plugin-nuklear
BACKEND("SDL")
<.....>
This will force the Canvas wrapper to use SDL. If you run the program now, does it still show a lag? You could try with BACKEND("GLFW") and BACKEND("ALLEGRO") also, if you have these libs installed on your RPi. (3) Lastly, note that the Canvas wrapper depends on dynamic loading of functions during runtime. Generally, this is slower than linking the binary during compile time. Your demonstration programs use the latter, while the Canvas wrapper uses the dynamic loading during runtime. It might be worthwhile to experiment with the environment variable LD_LIBRARY_PATH, by putting the important directories containing OpenGL libraries before others. HTH Peter[/i]
|
|
|
Post by vovchik on Oct 6, 2018 15:08:42 GMT 1
Dear Peter/Joe,
I tried BACKEND("SDL") on my PI and on an Athlon with nouveau/mesa and got:
Couldn't find matching GLX visual
on both machines.
Something not right with OPENGL, I think.
With kind regards, vovchik
|
|
|
Post by Pjot on Oct 6, 2018 19:26:28 GMT 1
Added the the last primitive 'NK_COMMAND_IMAGE' in the Nuklear drawing backend. It enables images onto widgets and also plain drawing. To add images, first load them as RGBA quadruples into memory (by using the STB library for example), then create a texture, and from this obtain the nk_image reference. This reference then can be used during widget creation. The new demo program shows how it works. Updated files: This concludes the Nuklear drawing backend, it should be complete now. Regarding the discussed lag, please try to see if 'glxinfo' actually shows a 'visual', for example: On my system, there are 84 visuals available.
Regards Peter EDIT: updated the Nuklear Plugin so it contains the texture generation as well - version 0.7 now. Attachments:
|
|