no... but if I can get a mbp retina, I can take a look and make it work ;)

:) Not sure that this is for tomorrow. :D BTW you can remind nicolas that he is the only one of the team that has an SSD disc. Stef

Tudor Girba-2 wrote

Did anyone find a solution to this problem?

I just got used to the fuzziness :) -- View this message in context: http://forum.world.st/Pharo-on-retina-display-tp4642567p4650783.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sorry but we are a tiny team and we cannot run after everything at the same time. We should get focused and release something. Igor is already fixing the VM plugin, library loading to avoid to have two libraries of a given plugin and all the conflicts going together. And we do not have retina mac right now. Stef

:(

On Thu, Oct 11, 2012 at 3:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote: Tudor Girba-2 wrote

...

Did anyone find a solution to this problem?

I just got used to the fuzziness :)

-- View this message in context: http://forum.world.st/Pharo-on-retina-display-tp4642567p4650783.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- www.tudorgirba.com

"Every thing has its own flow"

On 12 October 2012 11:06, Esteban Lorenzano <estebanlm@gmail.com> wrote:

also, the "retina problem" is a much more complex problem than it looks: it exposes how aged (obsolete is a better word, I think) is our graphics system. Now, Athens will solve that problem, but there is no magic to do that can make the old graphics infrastructure to work with new hardware requirements, any adaptation of it will take a lot of work, and probably will not reach a good place... So, IMO the way to go is continue the efforts for make Athens work, and move morphic to work with it as soon as possible.

Yes, best thing for retina displays is to use Athens. It is maybe not yet ready for prime time, but of course it is more than nothing, and i crawling slowly to finish line :) I can only say that it was right strategic choice to put effort in developing it. Because if we wouldn't make such choice few years ago, and allocate our resources to other tasks (and there's plenty), there would be nothing to propose at all to support new generation of hardware which comes these days. :)

Esteban

ps: what? are you saying that we should remove something that is there since 1980? Yes I am! :)

On Oct 12, 2012, at 10:48 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Sorry but we are a tiny team and we cannot run after everything at the same time. We should get focused and release something. Igor is already fixing the VM plugin, library loading to avoid to have two libraries of a given plugin and all the conflicts going together. And we do not have retina mac right now.

Stef

...

:(

On Thu, Oct 11, 2012 at 3:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote: Tudor Girba-2 wrote

...

Did anyone find a solution to this problem?

I just got used to the fuzziness :)

-- View this message in context: http://forum.world.st/Pharo-on-retina-display-tp4642567p4650783.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- www.tudorgirba.com

"Every thing has its own flow"

-- Best regards, Igor Stasenko.

On 12 October 2012 13:41, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

Athens would indeed be great. And I am happy that this investment has high priority in the team. But, I think for the usages that I see, we would need font support. Is there any progress on this front?

Font support is there. I currently working on Morphic rendering (see screenshot) and getting VMs for all 3 platforms Athens-ready. As i said previously, don't expect Athens to support raster fonts. It doesn't makes any sense. With athens, you can always render number of glyphs into bitmaps and draw them as bitmaps later, if you want it, but i wouldn't call it 'font support', it is bitmap support. :) For Cairo backend i did integration with freetype (which already in pharo as you know), which means that you can render any scalable fonts. And if you may know, freetype package supports embedded fonts (i.e. font data loaded from memory), which means you don't even need to have a separate font file along the image, you can keep font in image itself. As for amount of memory, needed to hold truetype font in image: we did a small experiment with Camillo few days ago , we took single font (Deja Vu sans mono), and edited it to have only ascii character set (0..127). The resulting font file size is just 30Kb! Now compare it with following: (StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory ]) sum 1504444 1.5 Mb of bitmap data for only single raster font with couple fixed sizes. For same size, you could have 1500/30 = 50 various vector fonts (if only ascii character range of course).

Cheers, Doru

-- Best regards, Igor Stasenko.

Hi Igor, The only reason we were thinking of the bitmap font support was that there was no ready-made vm to get people to use the new canvas. But, if you are getting the vms ready ... this is fantastic. I would say that as soon as they are ready Moose will likely move to Athens. Cheers, Doru On Fri, Oct 12, 2012 at 2:42 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 12 October 2012 13:41, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi,

Athens would indeed be great. And I am happy that this investment has high priority in the team. But, I think for the usages that I see, we would need font support. Is there any progress on this front?

Font support is there. I currently working on Morphic rendering (see screenshot) and getting VMs for all 3 platforms Athens-ready.

As i said previously, don't expect Athens to support raster fonts. It doesn't makes any sense. With athens, you can always render number of glyphs into bitmaps and draw them as bitmaps later, if you want it, but i wouldn't call it 'font support', it is bitmap support. :)

For Cairo backend i did integration with freetype (which already in pharo as you know), which means that you can render any scalable fonts.

And if you may know, freetype package supports embedded fonts (i.e. font data loaded from memory), which means you don't even need to have a separate font file along the image, you can keep font in image itself. As for amount of memory, needed to hold truetype font in image: we did a small experiment with Camillo few days ago , we took single font (Deja Vu sans mono), and edited it to have only ascii character set (0..127). The resulting font file size is just 30Kb!

Now compare it with following:

(StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory ]) sum 1504444

1.5 Mb of bitmap data for only single raster font with couple fixed sizes.

For same size, you could have 1500/30 = 50 various vector fonts (if only ascii character range of course).

...

Cheers, Doru

-- Best regards, Igor Stasenko.

-- www.tudorgirba.com "Every thing has its own flow"

This is a great news Alexandre On Oct 12, 2012, at 2:56 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 12 October 2012 15:01, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi Igor,

The only reason we were thinking of the bitmap font support was that there was no ready-made vm to get people to use the new canvas.

But, if you are getting the vms ready ... this is fantastic. I would say that as soon as they are ready Moose will likely move to Athens.

Today we got a meeting a one of the decisions made is that Pharo 2.0 will be shipped with Athens-ready VMs. As well as Athens will be included as a technology-preview in release.

This is what people want from me, and i need to deliver :)

...

Cheers, Doru

-- Best regards, Igor Stasenko.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 13 Oct 2012, at 08:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Hi Igor,

The only reason we were thinking of the bitmap font support was that there was no ready-made vm to get people to use the new canvas.

But, if you are getting the vms ready ... this is fantastic. I would say that as soon as they are ready Moose will likely move to Athens.

Yes Igor is working on the three platforms. Igor is fixing the windows one currently and he is near the end. We are going to release vm with NativeBoost, Freetype, SSL support on all platforms.

Yes, yes, yes !! It's a long road, but we are moving forward on so many fronts, it will be non-linear indeed.

Stef

...

Cheers, Doru

On Fri, Oct 12, 2012 at 2:42 PM, Igor Stasenko <siguctua@gmail.com> wrote: On 12 October 2012 13:41, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi,

Athens would indeed be great. And I am happy that this investment has high priority in the team. But, I think for the usages that I see, we would need font support. Is there any progress on this front?

Font support is there. I currently working on Morphic rendering (see screenshot) and getting VMs for all 3 platforms Athens-ready.

As i said previously, don't expect Athens to support raster fonts. It doesn't makes any sense. With athens, you can always render number of glyphs into bitmaps and draw them as bitmaps later, if you want it, but i wouldn't call it 'font support', it is bitmap support. :)

For Cairo backend i did integration with freetype (which already in pharo as you know), which means that you can render any scalable fonts.

And if you may know, freetype package supports embedded fonts (i.e. font data loaded from memory), which means you don't even need to have a separate font file along the image, you can keep font in image itself. As for amount of memory, needed to hold truetype font in image: we did a small experiment with Camillo few days ago , we took single font (Deja Vu sans mono), and edited it to have only ascii character set (0..127). The resulting font file size is just 30Kb!

Now compare it with following:

(StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory ]) sum 1504444

1.5 Mb of bitmap data for only single raster font with couple fixed sizes.

For same size, you could have 1500/30 = 50 various vector fonts (if only ascii character range of course).

...

Cheers, Doru

-- Best regards, Igor Stasenko.

-- www.tudorgirba.com

"Every thing has its own flow"

On 12 October 2012 15:28, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:

On 12.10.2012 14:42, Igor Stasenko wrote:

...

On 12 October 2012 13:41, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi,

Athens would indeed be great. And I am happy that this investment has high priority in the team. But, I think for the usages that I see, we would need font support. Is there any progress on this front?

Font support is there. I currently working on Morphic rendering (see screenshot) and getting VMs for all 3 platforms Athens-ready.

As i said previously, don't expect Athens to support raster fonts. It doesn't makes any sense. With athens, you can always render number of glyphs into bitmaps and draw them as bitmaps later, if you want it, but i wouldn't call it 'font support', it is bitmap support. :)

For Cairo backend i did integration with freetype (which already in pharo as you know), which means that you can render any scalable fonts.

And if you may know, freetype package supports embedded fonts (i.e. font data loaded from memory), which means you don't even need to have a separate font file along the image, you can keep font in image itself. As for amount of memory, needed to hold truetype font in image: we did a small experiment with Camillo few days ago , we took single font (Deja Vu sans mono), and edited it to have only ascii character set (0..127). The resulting font file size is just 30Kb!

Now compare it with following:

(StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory ]) sum 1504444

1.5 Mb of bitmap data for only single raster font with couple fixed sizes.

For same size, you could have 1500/30 = 50 various vector fonts (if only ascii character range of course).

25 then, StrikeFonts cover all of latin1 range :) How is the rendering performance compared to Bitmap and FT fonts done without athens/cairo? Bitmapped FT fonts were somewhat of a hog both memory and performance-wise iirc, due to the combination of sub-pixel accurate glyph bitmap cache and glyph-by-glyph rendering...

According to my measurement, which i did a while ago, a freetype glyph rendering roughly takes 1/3 of total time for delivering glyph to the screen. Which means a worst slowdown if you do it without any caching is +1/3 total rendering time for text. This actually shows that rendering is memory bound. Freetype producing grayscale glyphs 8 bit per pixel, and blitting it on screen uses 32 bit bitmap . That's the only one reasonable explanation to my observations i found.

Impressive progress!

Cheers, Henry

-- Best regards, Igor Stasenko.

On 12.10.2012 11:06, Esteban Lorenzano wrote:
> also, the "retina problem" is a much more complex problem than it looks: it exposes how aged (obsolete is a better word, I think) is our graphics system. Now, Athens will solve that problem, but there is no magic to do that can make the old graphics infrastructure to work with new hardware requirements, any adaptation of it will take a lot of work, and probably will not reach a good place...
> So, IMO the way to go is continue the efforts for make Athens work, and move morphic to work with it as soon as possible.
>
> Esteban
>
> ps: what? are you saying that we should remove something that is there since 1980? Yes I am! :)
I think, if not ideal, it could at least reach an interesting place if 
some consessions were to be made.
- Giving up the World bitmap as a canonical bit-identical rendering on 
all platforms, and treat it more as a convenient place to grab contents 
for screenshots once in a while.
In that case, what would need to be replaced if one were to use morphs 
mostly unaltered, is a way to fetch the current contents of a region of 
the screen buffer during a display cycle (for doing alpha blending 
in-image).

Basically, instead of going
graphic primitives -> paint on World bitmap -> display World bitmap 
onscreen
you could then do
graphic primitives -> paint on platform structures -> display platform 
structures onscreen -> synchronize World bitmap with platform structures

and achieve pretty good consistency image-side with what is available today.

IIRC, Athens goes
Athens graphics primitives -> paint on backend structures (f.ex. Cairo) 
-> copy backend structures to World bitmap -> display World bitmap onscreen

So the underlying way of how to actually display shapes onscreen hasn't 
changed much (at least the last time I looked at it), it still displays 
a bitmap, and that's it.

Cheers,
Henry