PureBasic Forums - English

idle wrote: Sat Nov 23, 2024 4:34 am Good to hear about the progress and you don't hold back on getting it right!

Hehe yup, it's a fundamental UI building block so it was worth spending some time getting it right (maybe too much time and overkill lol), thanks man

PrincieD wrote: Sat Nov 23, 2024 5:09 am

idle wrote: Sat Nov 23, 2024 4:34 am Good to hear about the progress and you don't hold back on getting it right!

Hehe yup, it's a fundamental UI building block so it was worth spending some time getting it right (maybe too much time and overkill lol), thanks man

The time and effort to get it right is worth it.

idle wrote: Sat Nov 23, 2024 5:12 am

PrincieD wrote: Sat Nov 23, 2024 5:09 am

idle wrote: Sat Nov 23, 2024 4:34 am Good to hear about the progress and you don't hold back on getting it right!

Hehe yup, it's a fundamental UI building block so it was worth spending some time getting it right (maybe too much time and overkill lol), thanks man

The time and effort to get it right is worth it.

Absolutely mate!

that's an impressive compile size reduction

Zach wrote: Mon Nov 25, 2024 11:07 pm that's an impressive compile size reduction

Mainly thanks to Fred's new 'C' DLL linker but yeah the code is a lot more optimised, there was a lot of boiler plate in the old ProGUI

https://www.youtube.com/shorts/S74TJBKgzBw

So this might not look like much but it's a beauty of an optimisation, there is a DPICache of borders and image / masks that are pixel perfect (and rendered per monitor) which swap seamlessly between rendering a 9 slice pre-baked version of the border where the sides can be stretched. To a full render when the width and height are too small.

https://www.youtube.com/shorts/eXauR8eppMw

PrincieD wrote: Sat Nov 30, 2024 7:04 am https://www.youtube.com/shorts/S74TJBKgzBw

So this might not look like much but it's a beauty of an optimisation, there is a DPICache of borders and image / masks that are pixel perfect (and rendered per monitor) which swap seamlessly between rendering a 9 slice pre-baked version of the border where the sides can be stretched. To a full render when the width and height are too small.

https://www.youtube.com/shorts/eXauR8eppMw

That's really amazing. I wouldn't know where to start. I hope progui has more customers than just purebasic users. It's really impressive.

idle wrote: Sat Nov 30, 2024 9:54 am

PrincieD wrote: Sat Nov 30, 2024 7:04 am https://www.youtube.com/shorts/S74TJBKgzBw

So this might not look like much but it's a beauty of an optimisation, there is a DPICache of borders and image / masks that are pixel perfect (and rendered per monitor) which swap seamlessly between rendering a 9 slice pre-baked version of the border where the sides can be stretched. To a full render when the width and height are too small.

https://www.youtube.com/shorts/eXauR8eppMw

That's really amazing. I wouldn't know where to start. I hope progui has more customers than just purebasic users. It's really impressive.

Thanks mate

Why the hell did I get into UI coding

Hi guys, new border code integrated with WIP widget caching.

https://www.youtube.com/watch?v=XjvMzXjYlZ0

Notice how the Webview2 playing a YouTube video is composited correctly along with the Win32 button (now with rounded corners due to the border). Still some optimisations to make too with the work in progress widget caching (alpha masking is expensive). Also bare in mind this is running in debug mode on a 14 year old laptop using integrated GFX (the dedicated 880M GPU died the other year). Notice also there are no window resize artifacts no matter how complex the rendering scene is (which I believe is a first for Windows DirectX 11/Direct2D).

I've also extended the CreateImg() command now with an optional PixelFormat parameter: CreateImg(Width, Height, BackgroundColor = #PG_Img_Transparent, PixelFormat = #PG_Img_Format_BGRA32)

Which currently can be either #PG_Img_Format_BGRA32 (the default) or #PG_Img_Format_A8 (useful for alpha masking and GPU optimised)

Cheers!

Seeing some really good rendering performance improvements with the 'work in progress' widget caching and progressing well!

PrincieD wrote: Sun Dec 08, 2024 3:16 am Seeing some really good rendering performance improvements with the 'work in progress' widget caching and progressing well!

looking really good and the caching sounds like a good idea.

idle wrote: Sun Dec 08, 2024 7:58 am

PrincieD wrote: Sun Dec 08, 2024 3:16 am Seeing some really good rendering performance improvements with the 'work in progress' widget caching and progressing well!

looking really good and the caching sounds like a good idea.

Thanks yea it's been tricky to implement especially with nested layouts and when to flag a full redraw but you can imagine if you have a widget with 3 nested layouts for example the renderer only has to blit the cached version of the top level widget (if not flagged to redraw through size change etc) saving the renderer from having to delve into the children and do a full render of the contents of each one. If the top level widget needs to be redrawn then it might only need to do a simple blit of the cached versions of the nested child widgets too and so on. I needed to get this system in place too to be able to efficiently composite the alpha masks of borders as doing a BeginLayer() / EndLayer() (with border) is pretty slow. This also allows for a new WidgetSetOpacity() command

https://www.youtube.com/shorts/p3yJa_z2BY8

Debug overlay visualisation of widget caching

So when a widget has a green overlay it's drawing a cached version (just a bitmap) of the widget (and any nested widgets). When a widget has a red overlay it's re-drawing to the cached bitmap and then drawing the cached version and when there isn't a green or red overlay it's rendering the widget directly to window surface (or if the parent is cached, directly to the parent cached bitmap).
What's interesting is the layouts mostly resize the widgets constantly but what you see is an even distribution of drawing/blitting cached versions (or re-drawing and blitting cached version) or rendering directly.
The algorithm only uses/creates a cached version when the size is the same from the previous frame (a possible tweek is using the last 2 frames). So the idea is when the size of a widget has changed from the previous frame there's no point rendering to an intermediate buffer and then rendering that, just render directly and only when the size has settled then render to cache and use the cache.

Widget caching is working really great! just a few more optimisations - hopefully another Alpha version before Christmas and then then final peice of the puzzle is the skinning engine for the core framework (hopefully shouldn't take too long).

I've also added a new optional RedrawFlags parameter to RedrawWidget() which can be #PG_Redraw_AllChildren (under most circumstances you won't have to worry about this)