dalerank / nanogui-sdl

Minimalistic port of NanoGUI claim works with SDL API w/o external dependencies.
Other
437 stars 77 forks source link

I have a problem with 100% CPU use and incorrect rendering #53

Closed Fredrum closed 2 years ago

Fredrum commented 3 years ago

Hello! I am making a new version of Chiaki for the Raspberry Pi! For the old/current version see here,
https://www.youtube.com/watch?v=9TIIiuy_Hxk

For this new version I'm trying to use your nanogui-sdl because it allows me to do DRM direct to screen rendering when not under a X server. But I am also intending to support regular X desktop use.

Iv'e blocked out some basic elements of my GUI using nanogui-sdl but every time I launch I get 100% CPU use for the first 15-20 seconds and also at that time the rendering is incorrect. For example as you can see in the video the transparency of the pink and blue window is not respected and there are also issues with re-scaling of the windows. Another thing is that during that initial period if I have text fields open the whole screen flashes with the cursor blinking. Here's a video showing some of these things happening,

https://www.youtube.com/watch?v=yYLUT5W-QeE

I see that there is not much work in this Repo right now but I was hoping you would be able to tell me what these issues are? If there's anything I can do to fix them?

I am using Raspberry Pi 4b 32bit Buster SDL2 2.0.17 Mesa 21.3.0

UPDATE: I just realised that this does not happen in the example program so I will do some more problem solving to identify the cause.

Thank You

Fredrum commented 3 years ago

Hmm I'm turning things on and off and it seems to be the combination of using lines like, top_win->setFixedSize(Vector2i(screenSize.x, screenSize.y*0.5)); together with the performLayout(sdl_renderer);

thats causing the extended 80% cpu uses. Not sure how I can get around it though as I can't get regular setSize() to actually change the size of the windows. It seems like the performLayout is having trouble with the fixedSize.

Fredrum commented 3 years ago

I've just been running the google gperf profiler on this and see that it looks like the 'nanort' is the culprit. And noticing that 'rt' is for raytracing that starts to make sense.

 152  21.5%  21.5%      152  21.5% nanort::::float3::operator[]
  65   9.2%  30.6%       65   9.2% nanort::::IntersectRayAABB
  39   5.5%  36.2%       39   5.5% nanort::::TriangleIsect
  39   5.5%  41.7%       39   5.5% nanort::::float3::float3
  29   4.1%  45.8%       29   4.1% nanort::::float3::operator-
  29   4.1%  49.9%       29   4.1% nanort::::vcross
  29   4.1%  54.0%      101  14.3% nanort::BVHAccel::MultiHitTraverse
  14   2.0%  55.9%       14   2.0% __gnu_cxx::__normal_iterator::__normal_iterator
  13   1.8%  57.8%       56   7.9% nanort::::MultiHitTestLeafNode
  13   1.8%  59.6%       13   1.8% nanort::::vdot

I can't see any nanort files in the original project so I'm wondering if you have any clues for if there's a way to get nanogui-sdl working without the raytrace code?

dalerank commented 2 years ago

UI use software render for rasterize textures So not surprise you take 100% of cpu on start

dalerank commented 2 years ago

Can you share sample?

Fredrum commented 2 years ago

I will upload my wip code and link here tonight my evening!

i'm surprised about you saying it sw renders? It says its using opengl/gles2 to render so shouldn't that mean HW render?

dalerank commented 2 years ago

look inside button.cpp struct Button::AsyncTexture { int id; Texture tex; NVGcontext* ctx = nullptr; SDL cant provide opengl renderer If you want using hw renderer like opengl/dx/vulkan may be you need https://github.com/dalerank/nanogui or ImGUI

dalerank commented 2 years ago

It special mode, with software render, because I want to create lib for SDL only without external depedencies from dx, ogl, vulkan

Fredrum commented 2 years ago

Hm I'm not following when you say that SDL cannot supply opengl render context because my code says that I'm getting openGL under X11 and gles2 outside X11. There are other people that made me aware of this as I was trying to find a combination of openGL gui + kmsdrm rendering and it turns out SDL2 fits the bill. I then just needed a nice GUI framework that ran on top of SDL2. I'll show you my code later tonight after work.

Fredrum commented 2 years ago

The problem with many other GUI frameworks (orig Nanogui for example) is that they are based on GLFW, and GLFW does not support kmsdrm render which I need.

Fredrum commented 2 years ago

Hi! So here is the in-progress code that I'm working with. The main.cpp creates the gl context through SDL2,

https://github.com/Fredrum/chiaki/blob/rpi02/rpi/src/main.cpp

and this is where I have my gui code, https://github.com/Fredrum/chiaki/blob/rpi02/rpi/src/gui.cpp

Like I mentioned before the print messages from main.cpp reports that the renderer is openGL and gles2 depending on if Im using X11 or not.

(you'll not be able to build the project as the build setup has not been done yet)

dalerank commented 2 years ago

this port was developed for embedded system without any graphics cards, like mts250/sul4xx and other they have native sdl implementation but have no hardware for graphics sorry, if it not that you need. May be imgui? it have native SDL implementation

dalerank commented 2 years ago

You can look at https://github.com/dalerank/nanogui-sdl/tree/34a0c8709716854a48d291991b32c306786c4cb5 this is last commit with hardware render I think

Fredrum commented 2 years ago

Thank you I completely understand! No problem and thank you for the clarification and pointers!

Cheers!