[Bf-committers] Icon scaling

[Campbell Barton]

Hi Again,

On Tue, Nov 8, 2011 at 8:35 PM, Stephan Aßmus <superstippi at gmx.de> wrote:
> Hi,
>
> On 08.11.2011 04:08, Campbell Barton wrote:
>> Firstly I think the main issue with getting this into blender is
>> finding someone with the time who wants to work on this.
>
> I was kind of offering to do it, but I would have to experiment with my
> rendering code, to implement the shape hinting in the first place. Or
> else it provides no benefit to scaled down bitmaps. I have no idea if I
> even have the time, but it's one of the things I would love to work on,
> and I just wanted to gauge interest after seeing that Blender could
> benefit from this.

Ah, I wasn't sure, we get enough well meaning mails asking for _other_
people to work on projects.

btw, I should mention that I didn't write the existing icon system and
have only done a bit of interface code and worked a little on our font
rendering code, so I'm not exactly in a position to give this the
`go-ahead` but I have an idea on how it could work.

>> Regarding implementation -
>> Even if the icons render fast, we would still need to pass them to
>> OpenGL, while probably not _really_ slow doing this every draw, its a
>> step backward from using a textures which are fast. I'd expect we
>> would end up doing something similar to fonts where the vector data
>> generates a texture at different sizes.
>
> Yes, the generated bitmaps would have to end up in some cache, or it
> would be too expensive. One may even want to put them into a persistent
> cache so it doesn't slow down program startup each time. That being
> said, the rendering is really extremely fast. In Haiku, we do have an
> icon cache based on the resulting bitmaps in the file manager, but the
> first time icons are needed, they are loaded from disk as vector icons,
> parsed from the format into the shape data model and then rendered. It
> seems that the reduced disk size compared to PNGs or other formats, and
> thus faster loading time compensates the additional rendering time. At
> least I was careful not to introduce a perceptable delay when working on
> this stuff.
>
>> However at this point we can probably just get away with using larger
>> icons - 32x32 for eg - and it will be `good enough`,
>
> That may indeed be the case.

For an icon system I think we first need to deciede weather having
precise, crisp-hinted icons at any zoom level is worth adding at all.

To simply have less blurry icons we can always use higher res icons
(as said before - 32x32 or so) - use a bitmap generated from svg,
whatever..
in that case we can manage any way we like - automatic render a png
from SVG's and cache or use you're format, the point is that it ends
up as a bitmap that blender can load the same way we do now, so theres
not really any design change internally.


However you're system is a step up from this, so I'll give my
suggestion on how it could be done.

* runtime icon cache *
This could be done in a generic non-blender-spesific way - other
OpenGL apps could use for eg, and would work a lot like our font
rendering does now (see 'source/blender/blenfont').
where we lazy initialize icons into opengl texture memory at the
requested scale (with some stepping to avoid storing 1.001 vs 1.002 as
different textures), the main advantage with this IMHO is small size
on disk and the ability to load and remove vector icons at runtime.

Rebuilding different resolution icon sets, while fast wont come for
free, though lazy initialization each icon would likely make it a non
issue though.


* generated mipmaps *
This is basically what we do now but rather then having one image,
store multiple resolutions 10, 12, 14, 16.. etc. This is simple since
we don't need to do much to change the icon system, but is a bit
clumsy still since blender would need to come with all images. and if
we keep storing each resolution as a separate image - we'd need to
load the whole image just to draw 1 icon at a different size.
The icon storage could be shuffled on disk to allow efficient loading
of individual icons at different resolutions, so I think both could
work ok.

Main advantage with this is we get benefits of hinting without having
to link with any new libs or include vector rasterizing code.

Storing multiple resolutions of our icons will use more video texture
memory, again, lazy init means we save some too (currently we load all
but they are so small its not really an issue).

---

Suggest to start by making a small standalone OpenGL app that can draw
a grid of icons at - zooming in and out, lazy filling an internally
maintained list of icon textures, this is very much like `blenfont`
except we use freetype to fill the textures, useful reference if
you're not familier with dynamic allocating opengl textures for
rendering.
Once this works its mostly a matter of integrating it into blender
which other devs can help with.

If you are serious about going ahead with this, best let us know and
get a +1 from one of the other UI devs too.


>> Something else to consider when updating the icon system is to allow
>> addons to use their own icons.
>
> To understand what problem you are referring to, I would have to become
> familar with the codebase. :-)

This is more of a detail to think of later, but if a new icon system
was made would be good to support adding icons at runtime, we could
add this to our existing system too, just something to keep in mind
since Im sure addon authors would really like it.


>> btw -  With SDL1.3 you should be able to run blender, though I'm not
>> sure how far along the SDL1.3 port is.
>
> I was helping to mentor the GSoC project to port SDL 1.3 to Haiku,
> reviewing the patches and providing a lot of input. It's another item on
> my TODO list to help improve this more, but I am pretty sure our OpenGL
> implementation needs more work in general, SDL is just another client of
> that API and whether or not it is used directly or indirectly, it needs
> to improve. :-)

If you can use software mesa opengl you could use that until hardware
supported better.

>
> Thank you for your feedback!
>
> Best regards,
> -Stephan
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell