but, Norbert, I don't see the point. In a server you will not have (or *should* 
not have) a display... so rendering time, etc. is non an issue, because it will 
not be any... or I'm missing something?

cheers,
Esteban

On Apr 24, 2012, at 2:02 PM, Norbert Hartl wrote:

> 
> Am 24.04.2012 um 12:50 schrieb Igor Stasenko:
> 
>> On 24 April 2012 11:44, Norbert Hartl <[email protected]> wrote:
>>> 
>>> Am 24.04.2012 um 11:35 schrieb Geert Claes:
>>> 
>>>> 
>>>> Norbert Hartl wrote
>>>>> 
>>>>> Of course, if there is an ugly replacment that can be used if the system
>>>>> is minimised. Having two icon sets introduces the possibility to make the
>>>>> ugly one consume even less memory, e.g. make it black and white.
>>>>> 
>>>> 
>>>> I have no idea what you just tried to say :)  When you say ugly 
>>>> replacement,
>>>> are you talking about the current ugly icons or do you find Esteban's
>>>> suggested icons not appealing enough?
>>>> 
>>> It is just an addition to my first statement. If we call the current icon 
>>> set medium in the sense of medium cutiness and medium memory consumption 
>>> than there is a new situation with the new nice icons. Igor is right, if 
>>> the vector world is coming to pharo then it is easy to make really good 
>>> looking icons in the image. But the memory consumption and CPU intensity 
>>> will be raised. That contradicts to usage of pharo in a server environment. 
>>> So what I was saying is that I think that the new icons are great. But then 
>>> there should be a replacement for it when the image is shrinked. The same 
>>> happens with the fonts if you shrink. And if the icons are replaced they 
>>> could even be replaced by something really basic that saves additional 
>>> memory. On a server with VNC or the like the icons aren't that important 
>>> and maybe can be removed completely.
>>> 
>>> More clear now?
>>> 
>>> Norbert
>>> 
>>> 
>> 
>> did i miss something? since when memory consumption for vector
>> graphics takes more space?
>> look at the size of .svg files and compare them with size of .png
>> files for same icons.
> 
> There is a difference between storage size and in-memory size. The storage 
> size is important if you put the resource class-based. For the rest you need 
> to decide. Either you render the icon every update from source or you do 
> cache and from then on you have storage size + in-memory size for your icons. 
> If you do fancy stuff automatically which means it probably uses a lot of 
> colors so this can be quite big. 
> 
>> Vector data are much more compact.
>> So, actually if you really want to shrink things down, you need to
>> operate with vectors :)
> 
> Yes, and then you need a lot of cpu cycles. Just what I said. 
> 
>> More CPU for rendering vector graphics? Perhaps.
>> It is of course more expensive than just copying memory from one
>> bitmap to another.
>> But desktop environment requires a lot more complex operations that
>> just copying bits from one form over
>> another one.
>> And also consider the cases where you need to use 5 different
>> operations to simulate just one.
>> (look at famous corner rounder hack).
> 
> Again what I said. It is feasible to have good looking stuff. But everything 
> you said is unimportant on a server. I'm just begging you not to forget that. 
> That's all. Nothing against any of your plans. It will make pharo better.
> 
> Norbert


Reply via email to