you have 1 and 3 :) for svg, we still need to wait a bit :) On Apr 24, 2012, at 2:13 PM, Norbert Hartl wrote:
> > Am 24.04.2012 um 14:06 schrieb Esteban Lorenzano: > >> 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? >> > I think most people using pharo on the server are using VNC to maintain them. > I do that,too, in lack of a better tool. So in this case there is a display > and there are icons. Rendering is not an issue as long as you suspend to UI > thread until you need it. > So, let me just repeat > > ...new icons.... cool! > ...svg icons.....cool! > ...removable icons...cool! > > That's basically all I wanted to say. > > Norbert > >> 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 >> >> > >
