Scalable Icons

[oiaohm]

All MS Icons upto and include Window 2003 are a form of uncompressed bitmap.

Vista Icons are a new from. A from of wraped png files. Reason for the change 256x256 icon in the old format is just huge.

If reactos is going to support the huge Icons from Vista a png engine will be required anyhow. I see no reason why not to provide users with the means to use this engine directly if they wish without have to create a Vista Icon file.

Svg has it advantages for other reasons. Production of any size Icon that user wishs. Svg for base Icons is most likely a good idea. Simple to produce the required Icons in case of need more sizes.

Jpg does not really have any advantage over png in icons. Little bit smaller file. More processing require to produce image than png.

So I see at least 3 formats. Old Windows Icons, Vista Icons and png.

Maybe a forth SVG. Due to its scale effect of being a Vector graphic. SVG might be the format of the icons in a theme install file. So that themes don't need to be change with Icon size provide changes. The theme manager produces the platform required Icons.

I see SVG sneeking in somewhere. Either direct or indirect.

SVG support is only doing what was promissed would be in Vista anyhow.

Microsoft kinda backed out of that one.

[GreatLord]

svg will not be add as icon format in ReactOS

Real reason is it will slow down the drawing process alot.
svg need calc for example 16x16 before drawing it.
and the calc of scale vetor graphic is always slow.
even on morden computer.

Next problem is adding support to rc format
ms visualstudio can not include the svg data
as bitmap/icon and that make it pain in the ass
it req to hacked own rc standard on top of current
rc standard. and that make reactos not avail be compile
on VS.

Next problem is redesign win32k and gdi32 subsystem to accpect svg.

[oiaohm]

SVG indirect? Base form of all Reactos Icons where able.

Direct is a little different I would not say using SVG alone.

So if more sizes are required like 128x128 or something warped. No need to just scale icon and look nasty if not all ready in the ico file. Ie what happens from time to time 32x32 scaled to 128x128 and it does look bad. Just run a generator create icon application asked for from the base SVG.

It would be hacking the .ico format to put in direct. I would guess do like a id3 tag on the end of the .ico file hiding the svg. If Last 6 chars are rossvg there is a svg hidden and the 4 before the 6 the offest back to start of svg. This was VS does not see that there is a SVG there.

I don't know exactly how this rendering of icons is handled.

If application give system a ico file and asks for X size without know if its in there or not and the system rescales to suit. Then SVG could be slid in to get around scale problems. Not every icon render is going to cause a rescale. Of course it could have a registry switch. Nice icons at all times on or off if on check for svg if icon does not exist can create from svg if svg exist else just rescale. If off do the current methord.

Tell me if what I am saying here is completely impossable.

What gets me is a 600 mhz machine running linux can still render fine with SVG. Yes its not nuts it does not do small icons with SVG. 32x32+ only come from SVG in most cases and even they 32x32 might be still a png then 48x48+ is the starting point of the SVG. Because the smaller icons exist lots of the SVG render over head is avoided.

I would not call a 600 mhz machine exactly modern.

[MadRat]

Couldn't the win32k and gdi32 subsystems be made modular with the option to fork to a new library of png-based icons turned on at a later date? By designing it modular now you save mucho time later in the mod. In fact, instead of pigeonholing either-or, multiple modes 0-256 could be supported with the forks defined as they are developed. Would make new icon support less than a monolithic matter for future developers.

[etko]

Linux uses SVGs for years, they are maybe slower by several picoseconds like ICOs but you hardly notice the lag. PNGs are slow in they own right because of compression. Average Joe is completely clueless, and can't tell the difference. All that talk about being slow is ridiculous, I don't think that speed is real problem. Internal Windows antialiasing routine which stretches and blurs and otherwise processes icons when they are scaled up, say to 128x128 resolution, isn't lightning fast too, in my opinion. When you use it by API you can sometimes feel really nice lag before results appear. After the icon is cached, format in which actual icon was stored on disk is not important anymore.

GDI will be restructured one day, sooner or later, to support all that bloated UI theming script kiddies are trembling for. Anyway I believe that MS with their "oh, that's nice, we must steal that !" attitude, will come with some nostandard XML/SVG proprietary bullshit icon format anyway, in Vista or another Comb. If they already haven't.

So my conclusion is, that the only real point with SVGs is that they are not natively supported by VS an RC compiler. And the second one is, of course, that there is no developper wantig to undertake such task, and code the thing .