Using vector graphics as UI elements
lazarus / 31-LCL

----------------------------------------------------------------------
fatmonk · 2015-08-17 09:57

Is there any way to use vector graphics as UI elements?

I can see that TImage only seems to accept bitmap images (from the
file type list), but as my UI is scalable I'd like to be able to
something like an SVG.

(By the way, I've searched the forums and can only find mentions
scalable graphics in the context of loading them into and processing
them in an application written in Lazarus / fpc, not actually using
scalable graphics as part of the UI itself).

Thanks,

FM

----------------------------------------------------------------------
Blaazen · 2015-08-17 10:33

I don't know how to use *.svg icons directly.
However, it should be possible to bundle *.svg files with your
application (in resources, or simply *.svg files).
User will choose in Options size of toolbars (smoothly, lets say from
12 to 64 pixels). You will create ImageList dynamically, convert one-
by-one *.svg files to *.png and feed the ImageList. Finally, you will
assign this ImageList to toolbars.

----------------------------------------------------------------------
fatmonk · 2015-08-17 10:55

They're not for tool bar buttons, unfortunately, and they need to
scale dynamically rather than in size jumps.

An example of the usage is that I have a 'clock' centered at the top
of the UI. I'm currently using a rounded rectangle created with
BGRTools to give this clock a background so that it stands out
separate from the rest of the UI.

Although a rounded rectangle isn't really hat I want, I can scale it
as the UI size changes simply by changing its width and height
programmatically. Of course I could do this with a fixed png (or a set
of PNGs) but the scaling would create ugly edges. And I'd imagine
dynamically creating a new PNG as the UI is scaled (using the OnPaint
event as I'm using to scale the other UI elements) would be very
intensive...

-FM

----------------------------------------------------------------------
marcov · 2015-08-17 11:59

Quote from: fatmonk on August 17, 2015, 12:55:23 pmAnd I'd imagine
dynamically creating a new PNG as the UI is scaled (using the OnPaint
event as I'm using to scale the other UI elements) would be very
intensive...

What do you think what happens otherwise? Most GUI toolkits are bitmap
based, and stem from the days that render hardware couldn't be taken
for granted. Even today, win10 still must work on i965 graphics.

The only other option is to use an opengl widget. Then rescaling is
fairly cheap.

----------------------------------------------------------------------
Graeme · 2015-08-17 13:21

AggPas can read and dynamically render SVG images to any canvas size -
you don't need to implement any special OnPaint event handlers. It is
pretty fast without the need for hardware acceleration. It should
definitely be fast enough for general desktop apps (I'm not talking
about games here). How this would tie into LCL and for your needs - I
don't know.

----------------------------------------------------------------------
taazz · 2015-08-17 13:37

I have this link in my bookmarks
http://development.mwcs.de/svgimage.html with the note that it seems
to have imagelist functionality and marked as to be ported. It is
rather low in my current priority list so I haven't looked closer than
that. See if this helps you.

----------------------------------------------------------------------
fatmonk · 2015-08-17 16:12

I'll take a closer look at AggPas and the MWCS stuff in that case,
thanks.

I'm making do with the BGRShape elements in the short term as they
actually look OK for my purposes, but if I can get one of the other
two working all the better.

@marcov: I guessed internally they would be being rendered as a
bitmap, but I was thinking that by explicitly converting a vector to a
bitmap would be an extra step /before/ any internal bitmapping
happened for the actual display. I would expect, for example, that
even though a PNG is a bitmap, because it contains / can contain alpha
channel information, then the area that a bitmap covers is rendered
again as a new bitmap when the PNG is actually displayed, so as to
'show though' any elements below its transparent areas. (Though that
may well be a misconception based on how you see things actually draw
on a slow machine)

-FM