@popolon it's still dated hardware (2016). That was 6 years ago!
@carbonatedcaffeine So he can render at least at the speed from 10 times ago hardware, and probably at the speed of 5~6times ago hardware, it was on the top of ARM chips at this time.
@carbonatedcaffeine I Noticed by a htop, than, between the fact that #Cairo doesn’t use hardware acceleration, it is also mono-threaded, beside, probably wrong usage on my side, as a beginner in this toolkit, this doesn’t help either. This is still a high quality and fast renderer (and still very useful for output to SVG/PDF.
@popolon maybe a new solution is needed then.
@carbonatedcaffeine I believe I found why for it was so slow. when I launch the application, drawing is fast, but after “blanking the surface” it become slower, and it’s worst at each blanking ^^. If I restart the application it is very fast. For the demo, I made several tries, to not be too long on explanation, on the vidéo. If I quit
As I reused GTK4 tutorial example as base for blanking, it really looks like painting the surface for cleaning the screen, is adding a new element on stack, and then previews drawing has been cumulated in rendering stack, and everything is drawn at each event.
I didn’t found a reference to that in the manual, There is cairo recording surfaces, that record every draw to be played in another format. And notion of push/pop groups that can be used to render intermediate surface, as example.
I didn’t find this clearly in the part of the documentation, that explain the global mean of using all of this an efficient way for now.
@popolon oh I see
@carbonatedcaffeine I use a PinePhone Pro, not a Pinephone, that isn’t slow at all. There are 6 64bits cores, a powerfull Mali GPU, far more powerful, than phone from between 10 and 5 years ago, that was already able to do this kind of stuff or complex 3d games. There are bottlenecks to remove here.