Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

I think that there is a key aspect in the story: Risk management.
In addition I see the following problems: addition without removal.

- if we integrate bloc in the future it means that we will have Athens for
Morphic and the tools that we will use while
developing the rest AND Sparta for the external window.

Now I think that we should throw away Athens if it does not support the
future scenario but have
a Sparta-MorphicFriendly variation to replace Athens so that we can
continue to work.

I mean we CANNOT continue to stack libraries on the side of each others.
Because it makes us super slow to move.

This is also a part of risk management. Each time that we improve the
**current** infrastructure
we build a MILESTONE. If you want to go the everest you build intermediary
camps in case of tempest you can rest there and restart.
In Bloc and Brick I see no camp.

Let us look at SDL and OS-Window. So now it is bad and terrible.
If we do not do anything we will have MorphHand the ugly + SDL20 is not
useful + OSWindow the stupid + GTK the great
Come on this is not possible!

If you do not prepare integration and milestone I can tell you that the
integration will not happen.
And your risk gets higher and higher.

So far I did not see any roadmap and a roadmap should place such concerns
on the table.

For me having Bloc and Brick with horrible borders around the windows
would be just perfect.
And not having SVG support for hyper fancy morphs too.

Let us think incrementally.
Why we cannot have a scenario
- Default and Simple
- Advanced and risky where you load your mozz2d lib

Stef

PS: I agree with norbert.

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi

I am very thankful to all participants in the discussion!

Moz2D is not integrated in Pharo, it is an optional third party library
that helped us to model and provide architectural support of a variety of
features that were not possible with Morphic and are not possible with
Cairo (or not so easy to do). It does not mean that we hate Morphic or
dislike Cairo, it is just different :)

I read all emails very carefully and clearly understand your fears. "What
if he leaves?" "Do we want Esteban to maintain yet another VM related
stuff? (because when something breaks he is almost the only one who can
help, thanks!)" "Why is it 20Mb?!"

The point is to find balance of pros and cons. Exactly as you wrote: more
features => higher complexity => increase in costs => where to find
fundings.

I absolutely agree with the idea of having a "core" cheap backend that is
easy to maintain and costs almost nothing.

We are looking into a backend for Sparta based on Cairo.
Bindings will be based on the latest stable cairo-1.14.8 (
https://www.cairographics.org/news/cairo-1.14.8), we will also add support
of different surfaces including accelerated ones in order to be ready for
compiled cairo with enabled acceleration.

Cheers,
Alex

On 27 January 2017 at 12:36, Tudor Girba  wrote:

> Hi,
>
> > On Jan 27, 2017, at 12:20 PM, Esteban Lorenzano 
> wrote:
> >
> > (I was going to answer a big mail but my observations/concerns are
> mostly targeted by Norbert and Stef)
> >
> >> On 27 Jan 2017, at 10:49, Tudor Girba  wrote:
> >>
> >> Hi,
> >>
> >> Thanks for the detailed analysis.
> >>
> >> In summary, Cairo+Pango+SDL2 provide enough support to get a subset of
> Sparta working that would be equivalent with the Athens that we already
> have. In other words, with such a backend, when we would tell Sparta to use
> a blur effect, it will simply do nothing and the image environment can
> continue to work as it does now.
> >>
> >> I hope that everyone agrees that this is a reasonable fallback scenario
> that we can count on. And I think this is in line with what Stef was saying
> as well.
> >>
> >> With this in mind, we should also remember that the Moz2D backend works
> now which means that we can now focus on Brick to close the loop and
> provide a complete stack that more people can start utilizing, and we can
> come back to the alternative backend later.
> >>
> >> Does this path to action address the worry related to the future of
> Sparta backends?
> >
> > thanks Doru…. I think having a base system that works in all scenarios
> (even if we miss some features) and is easy to maintain is important.
>
> Ok, so this means that worry is addressed with this strategy.
>
>
> > Then you can have a different backend for complex stuff (is more or less
> the same about Ronie’s Wooden… I love to have the possibility of doing the
> things Ronie do with that, but I would never target to build my UI system
> on top of it).
>
> Of course, choosing a technology depends on the value that you want to
> create with it.
>
>
> > Even with this simplification, I would like to know why you choose to
> strip a library from a project instead testing, for example Skia (I know,
> Skia api is not stable, and is C++ and C bindings are still unstable), but
> well… others maybe.
>
> As I mentioned before, the stripping is only done for the text support
> part, not for the vector graphics support that Skia also supports. The
> Skia-equivalent part from Moz2D is compilable as is.
>
>
> > And some precisions:
> >
> > - SDL2 do allow transparent windows and windows without decorations.
> https://wiki.libsdl.org/SDL_SetWindowOpacity,
> https://wiki.libsdl.org/SDL_CreateWindow (and the flags section)
> > - Cairo do allow acceleration, we need to compile it with right backend.
> >   - I disagree is a dead technology. Instead, is a very mature
> technology… that’s why forum is not too active (even if as far as I see, it
> was never too active). Yes, maybe is not in the hype, but is cool and allow
> us to do very nice things.
> > - examples on images are slow because of how they are programmed, not
> because of cairo :)
>
> Great points. It looks like we already have the right knowledge in-house
> :).
>
>
> > cheers!
> > Esteban
> >
> > ps: instead “not doing anything” non-suported-operations could throw a
> notification (a silent one)?
>
> Sure.
>
> Doru
>
>
>
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >>
> >>> On Jan 26, 2017, at 11:45 PM, Aliaksei Syrel 
> wrote:
> >>>
> >>> Hi
> >>>
> >>> (My previous email was not a joke, I don't try to troll anyone. Let
> tolls do their job in other places)
> >>> Let's forget Moz2D for a moment :) Imagine that it does not exist. It
> was done just for fun and is even not in pharo repo. (
> https://github.com/syrel/Moz2D). We needed something that works and it
> was made investing just a few months of time of a single anonymous student
> during summer exams session and vacations.
> >>>
> >>> I would like to start maybe one of the mos

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi,

> On Jan 27, 2017, at 12:20 PM, Esteban Lorenzano  wrote:
> 
> (I was going to answer a big mail but my observations/concerns are mostly 
> targeted by Norbert and Stef)
> 
>> On 27 Jan 2017, at 10:49, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>> Thanks for the detailed analysis.
>> 
>> In summary, Cairo+Pango+SDL2 provide enough support to get a subset of 
>> Sparta working that would be equivalent with the Athens that we already 
>> have. In other words, with such a backend, when we would tell Sparta to use 
>> a blur effect, it will simply do nothing and the image environment can 
>> continue to work as it does now.
>> 
>> I hope that everyone agrees that this is a reasonable fallback scenario that 
>> we can count on. And I think this is in line with what Stef was saying as 
>> well.
>> 
>> With this in mind, we should also remember that the Moz2D backend works now 
>> which means that we can now focus on Brick to close the loop and provide a 
>> complete stack that more people can start utilizing, and we can come back to 
>> the alternative backend later.
>> 
>> Does this path to action address the worry related to the future of Sparta 
>> backends?
> 
> thanks Doru…. I think having a base system that works in all scenarios (even 
> if we miss some features) and is easy to maintain is important.

Ok, so this means that worry is addressed with this strategy.


> Then you can have a different backend for complex stuff (is more or less the 
> same about Ronie’s Wooden… I love to have the possibility of doing the things 
> Ronie do with that, but I would never target to build my UI system on top of 
> it). 

Of course, choosing a technology depends on the value that you want to create 
with it.


> Even with this simplification, I would like to know why you choose to strip a 
> library from a project instead testing, for example Skia (I know, Skia api is 
> not stable, and is C++ and C bindings are still unstable), but well… others 
> maybe. 

As I mentioned before, the stripping is only done for the text support part, 
not for the vector graphics support that Skia also supports. The 
Skia-equivalent part from Moz2D is compilable as is.


> And some precisions: 
> 
> - SDL2 do allow transparent windows and windows without decorations. 
> https://wiki.libsdl.org/SDL_SetWindowOpacity, 
> https://wiki.libsdl.org/SDL_CreateWindow (and the flags section)
> - Cairo do allow acceleration, we need to compile it with right backend. 
>   - I disagree is a dead technology. Instead, is a very mature 
> technology… that’s why forum is not too active (even if as far as I see, it 
> was never too active). Yes, maybe is not in the hype, but is cool and allow 
> us to do very nice things.
> - examples on images are slow because of how they are programmed, not because 
> of cairo :)

Great points. It looks like we already have the right knowledge in-house :).


> cheers!
> Esteban
> 
> ps: instead “not doing anything” non-suported-operations could throw a 
> notification (a silent one)? 

Sure.

Doru



>> 
>> Cheers,
>> Doru
>> 
>> 
>> 
>>> On Jan 26, 2017, at 11:45 PM, Aliaksei Syrel  wrote:
>>> 
>>> Hi
>>> 
>>> (My previous email was not a joke, I don't try to troll anyone. Let tolls 
>>> do their job in other places)
>>> Let's forget Moz2D for a moment :) Imagine that it does not exist. It was 
>>> done just for fun and is even not in pharo repo. 
>>> (https://github.com/syrel/Moz2D). We needed something that works and it was 
>>> made investing just a few months of time of a single anonymous student 
>>> during summer exams session and vacations.
>>> 
>>> I would like to start maybe one of the most important discussion that will 
>>> influence Pharo and will dictate how system will look like in a few years. 
>>> I invite everyone to join this discussion, especially board and consortium 
>>> members. Because here is where business starts.
>>> 
>>> There are some real questions:
>>> • Do we need Bloc or Morphic2 or %name your favourite framework%?
>>> • How advanced and modern do you want it to be?
>>> • What technology stack do we want to use for our new graphical 
>>> framework?
>>> • What platforms and operating systems do we want to support?
>>> • How flexible technology stack should be? (some parts may change in 
>>> the future)
>>> • Who will pay for it?
>>> • How many engineers can community afford?
>>> • Do you know how much other systems invest in graphical frameworks?
>>> • It is not a science project, isn't it?
>>> Let me first put my two cents in.
>>> 
>>> Low-level UI framework (without widgets) consists of multiple parts:
>>> • Vector graphics library to render shapes (fill, stroke, path builder, 
>>> composition and blending operators)
>>> • Font service library (to support different font formats and collect 
>>> information about local fonts installed in the system)
>>> • Text layout engine (this is where glyph positioning magic happens, 
>>> link above t

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Esteban Lorenzano]

(I was going to answer a big mail but my observations/concerns are mostly 
targeted by Norbert and Stef)

> On 27 Jan 2017, at 10:49, Tudor Girba  wrote:
> 
> Hi,
> 
> Thanks for the detailed analysis.
> 
> In summary, Cairo+Pango+SDL2 provide enough support to get a subset of Sparta 
> working that would be equivalent with the Athens that we already have. In 
> other words, with such a backend, when we would tell Sparta to use a blur 
> effect, it will simply do nothing and the image environment can continue to 
> work as it does now.
> 
> I hope that everyone agrees that this is a reasonable fallback scenario that 
> we can count on. And I think this is in line with what Stef was saying as 
> well.
> 
> With this in mind, we should also remember that the Moz2D backend works now 
> which means that we can now focus on Brick to close the loop and provide a 
> complete stack that more people can start utilizing, and we can come back to 
> the alternative backend later.
> 
> Does this path to action address the worry related to the future of Sparta 
> backends?

thanks Doru…. I think having a base system that works in all scenarios (even if 
we miss some features) and is easy to maintain is important.

Then you can have a different backend for complex stuff (is more or less the 
same about Ronie’s Wooden… I love to have the possibility of doing the things 
Ronie do with that, but I would never target to build my UI system on top of 
it). 
Even with this simplification, I would like to know why you choose to strip a 
library from a project instead testing, for example Skia (I know, Skia api is 
not stable, and is C++ and C bindings are still unstable), but well… others 
maybe. 

And some precisions: 

- SDL2 do allow transparent windows and windows without decorations. 
https://wiki.libsdl.org/SDL_SetWindowOpacity 
, 
https://wiki.libsdl.org/SDL_CreateWindow 
 (and the flags section)
- Cairo do allow acceleration, we need to compile it with right backend. 
- I disagree is a dead technology. Instead, is a very mature 
technology… that’s why forum is not too active (even if as far as I see, it was 
never too active). Yes, maybe is not in the hype, but is cool and allow us to 
do very nice things.
- examples on images are slow because of how they are programmed, not because 
of cairo :)

cheers!
Esteban

ps: instead “not doing anything” non-suported-operations could throw a 
notification (a silent one)? 

> 
> Cheers,
> Doru
> 
> 
> 
>> On Jan 26, 2017, at 11:45 PM, Aliaksei Syrel  wrote:
>> 
>> Hi
>> 
>> (My previous email was not a joke, I don't try to troll anyone. Let tolls do 
>> their job in other places)
>> Let's forget Moz2D for a moment :) Imagine that it does not exist. It was 
>> done just for fun and is even not in pharo repo. 
>> (https://github.com/syrel/Moz2D). We needed something that works and it was 
>> made investing just a few months of time of a single anonymous student 
>> during summer exams session and vacations.
>> 
>> I would like to start maybe one of the most important discussion that will 
>> influence Pharo and will dictate how system will look like in a few years. I 
>> invite everyone to join this discussion, especially board and consortium 
>> members. Because here is where business starts.
>> 
>> There are some real questions:
>>  • Do we need Bloc or Morphic2 or %name your favourite framework%?
>>  • How advanced and modern do you want it to be?
>>  • What technology stack do we want to use for our new graphical 
>> framework?
>>  • What platforms and operating systems do we want to support?
>>  • How flexible technology stack should be? (some parts may change in 
>> the future)
>>  • Who will pay for it?
>>  • How many engineers can community afford?
>>  • Do you know how much other systems invest in graphical frameworks?
>>  • It is not a science project, isn't it?
>> Let me first put my two cents in.
>> 
>> Low-level UI framework (without widgets) consists of multiple parts:
>>  • Vector graphics library to render shapes (fill, stroke, path builder, 
>> composition and blending operators)
>>  • Font service library (to support different font formats and collect 
>> information about local fonts installed in the system)
>>  • Text layout engine (this is where glyph positioning magic happens, 
>> link above too)
>>  • Text shaping engine (for high quality text rendering, to understand 
>> the problem => http://behdad.org/text/)
>>  • Complex script library (to support ligatures, split glyphs and other 
>> UTF8 stuff, remember 
>> https://github.com/minimaxir/big-list-of-naughty-strings)
>>  • Image processing library (for various image effects, like gaussian 
>> blur, morphology filter, gamma, displacement map, just to name a few)
>>  • Hardware acceleration. Software rendering is nice, however, modern 
>> UIs are full 

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi,

Thanks for the detailed analysis.

In summary, Cairo+Pango+SDL2 provide enough support to get a subset of Sparta 
working that would be equivalent with the Athens that we already have. In other 
words, with such a backend, when we would tell Sparta to use a blur effect, it 
will simply do nothing and the image environment can continue to work as it 
does now.

I hope that everyone agrees that this is a reasonable fallback scenario that we 
can count on. And I think this is in line with what Stef was saying as well.

With this in mind, we should also remember that the Moz2D backend works now 
which means that we can now focus on Brick to close the loop and provide a 
complete stack that more people can start utilizing, and we can come back to 
the alternative backend later.

Does this path to action address the worry related to the future of Sparta 
backends?

Cheers,
Doru



> On Jan 26, 2017, at 11:45 PM, Aliaksei Syrel  wrote:
> 
> Hi
> 
> (My previous email was not a joke, I don't try to troll anyone. Let tolls do 
> their job in other places)
> Let's forget Moz2D for a moment :) Imagine that it does not exist. It was 
> done just for fun and is even not in pharo repo. 
> (https://github.com/syrel/Moz2D). We needed something that works and it was 
> made investing just a few months of time of a single anonymous student during 
> summer exams session and vacations.
> 
> I would like to start maybe one of the most important discussion that will 
> influence Pharo and will dictate how system will look like in a few years. I 
> invite everyone to join this discussion, especially board and consortium 
> members. Because here is where business starts.
> 
> There are some real questions:
>   • Do we need Bloc or Morphic2 or %name your favourite framework%?
>   • How advanced and modern do you want it to be?
>   • What technology stack do we want to use for our new graphical 
> framework?
>   • What platforms and operating systems do we want to support?
>   • How flexible technology stack should be? (some parts may change in 
> the future)
>   • Who will pay for it?
>   • How many engineers can community afford?
>   • Do you know how much other systems invest in graphical frameworks?
>   • It is not a science project, isn't it?
> Let me first put my two cents in.
> 
> Low-level UI framework (without widgets) consists of multiple parts:
>   • Vector graphics library to render shapes (fill, stroke, path builder, 
> composition and blending operators)
>   • Font service library (to support different font formats and collect 
> information about local fonts installed in the system)
>   • Text layout engine (this is where glyph positioning magic happens, 
> link above too)
>   • Text shaping engine (for high quality text rendering, to understand 
> the problem => http://behdad.org/text/)
>   • Complex script library (to support ligatures, split glyphs and other 
> UTF8 stuff, remember https://github.com/minimaxir/big-list-of-naughty-strings)
>   • Image processing library (for various image effects, like gaussian 
> blur, morphology filter, gamma, displacement map, just to name a few)
>   • Hardware acceleration. Software rendering is nice, however, modern 
> UIs are full of fancy stuff that require hardware acceleration.
>   • Window and Event management library. With support of borderless and 
> semi-transparent windows + good support of touchpad.
>   • Custom written "Glue" library that allows all components to work 
> together. Since modern libs are implemented in C++ we would need to implement 
> C wrapper and a lot of integration tests.
>   • Make the whole beast cross platform.
> 
> Did I miss something?
> 
> Here are some modern technologies commonly used for mentioned parts:
>   • Skia, Direct2D, CoreGraphics, Cairo
>   • Fontconfig, Freetype2
>   • HarfBuzz
>   • Pango, OpenType
>   • Graphite2, FriBidi
>   • Imagemagic, SVG filters libraries
>   • Vulkan, OpenGL
>   • wxWidgets, QT, GTK, SDL2
>   • todo
>   • todo
> Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea!
> 
> Let's assume that we stop on Cairo + Pango. According to pango.com
> 
> The integration of Pango with Cairo (http://cairographics.org/) provides a 
> complete solution with high quality text handling and graphics rendering.
> 
> According to the this potential technology stack we will have:
>   • Cairo for vector graphics and rendering of basic shapes
>   • Pango for text rendering
>   • SDL2 for window and events management
> What we will not get:
>   • Support of filters; Cairo does not support gaussian blur. 3D 
> transformations, we will not be able to not implement card flip animation. 
> Never reach the same performance if using platform native frameworks (e.g. 
> Direct2D on windows). Cairo will not die, but there is zero progress.
>   • Vulkan support. Never with cairo. P

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Norbert Hartl]

Hi Alex,

thanks for the detailed mail. I can only share my gut feeling. And that is that 
you want too much at a time. We are still living in bitblt times and we need to 
escape from that. That means we need to have a proper vectorial support in our 
graphics backend. Having this we could use Bloc instead of Morphic. Adding 
proper font support is needed but comes after this. 3D graphics comes even 
later. etc. etc.

All of these features need to be modular anyway. Neither do you want to install 
all of these on every machine nor should the base image become huge. If these 
features are modular what is the problem doing them one after the other? If you 
would do one after the other you would give the community the opportunity to 
get used to the new stuff and help while you are doing the next thing. 

To make a long story short. I think by using an extracted version of moz2d you 
are not only using a monster but one that is not reliable and this is a risk 
for the overall goal. We all are waiting for vectorial graphics for so long I 
assume most of us can live without gaussian blur a little bit longer ;)

my 2 cents,

Norbert
> Am 26.01.2017 um 23:45 schrieb Aliaksei Syrel :
> 
> Hi
> 
> (My previous email was not a joke, I don't try to troll anyone. Let tolls do 
> their job in other places)
> Let's forget Moz2D for a moment :) Imagine that it does not exist. It was 
> done just for fun and is even not in pharo repo. 
> (https://github.com/syrel/Moz2D ). We needed 
> something that works and it was made investing just a few months of time of a 
> single anonymous student during summer exams session and vacations.
> 
> I would like to start maybe one of the most important discussion that will 
> influence Pharo and will dictate how system will look like in a few years. I 
> invite everyone to join this discussion, especially board and consortium 
> members. Because here is where business starts.
> 
> There are some real questions:
> Do we need Bloc or Morphic2 or %name your favourite framework%?
> How advanced and modern do you want it to be?
> What technology stack do we want to use for our new graphical framework?
> What platforms and operating systems do we want to support?
> How flexible technology stack should be? (some parts may change in the future)
> Who will pay for it?
> How many engineers can community afford?
> Do you know how much other systems invest in graphical frameworks?
> It is not a science project, isn't it?
> Let me first put my two cents in.
> 
> Low-level UI framework (without widgets) consists of multiple parts:
> Vector graphics library to render shapes (fill, stroke, path builder, 
> composition and blending operators)
> Font service library (to support different font formats and collect 
> information about local fonts installed in the system)
> Text layout engine (this is where glyph positioning magic happens, link above 
> too)
> Text shaping engine (for high quality text rendering, to understand the 
> problem => http://behdad.org/text/ )
> Complex script library (to support ligatures, split glyphs and other UTF8 
> stuff, remember https://github.com/minimaxir/big-list-of-naughty-strings 
> )
> Image processing library (for various image effects, like gaussian blur, 
> morphology filter, gamma, displacement map, just to name a few)
> Hardware acceleration. Software rendering is nice, however, modern UIs are 
> full of fancy stuff that require hardware acceleration.
> Window and Event management library. With support of borderless and 
> semi-transparent windows + good support of touchpad.
> Custom written "Glue" library that allows all components to work together. 
> Since modern libs are implemented in C++ we would need to implement C wrapper 
> and a lot of integration tests.
> Make the whole beast cross platform.
> 
> Did I miss something?
> 
> Here are some modern technologies commonly used for mentioned parts:
> Skia, Direct2D, CoreGraphics, Cairo
> Fontconfig, Freetype2
> HarfBuzz
> Pango, OpenType
> Graphite2, FriBidi
> Imagemagic, SVG filters libraries
> Vulkan, OpenGL
> wxWidgets, QT, GTK, SDL2
> todo
> todo
> Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea!
> 
> Let's assume that we stop on Cairo + Pango. According to pango.com 
> 
> 
> The integration of Pango with Cairo (http://cairographics.org/ 
> ) provides a complete solution with high quality 
> text handling and graphics rendering.
> 
> According to the this potential technology stack we will have:
> Cairo for vector graphics and rendering of basic shapes
> Pango for text rendering
> SDL2 for window and events management
> What we will not get:
> Support of filters; Cairo does not support gaussian blur. 3D transformations, 
> we will not be able to not implement card flip animation. Never reach the 
> same performance if using

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Hilaire]

Seriously??
You really don't want your base system (call it Pharo or Python or Ruby)
depends on such a stack. It could very liklely kill the whole base
system, particularly true for Pharo where UI is closely tight to the
rest of the system.
As external third party library, why not?

Hilaire

Le 26/01/2017 à 23:45, Aliaksei Syrel a écrit :
> 
> Low-level UI framework (without widgets) consists of multiple parts:
> 
>  1. Vector graphics library to render shapes (fill, stroke, path
> builder, composition and blending operators)
>  2. Font service library (to support different font formats and collect
> information about local fonts installed in the system)
>  3. Text layout engine (this is where glyph positioning magic happens,
> link above too)
>  4. Text shaping engine (for high quality text rendering, to understand
> the problem => http://behdad.org/text/)
>  5. Complex script library (to support ligatures, split glyphs and other
> UTF8 stuff,
> remember https://github.com/minimaxir/big-list-of-naughty-strings
> )
>  6. Image processing library (for various image effects, like gaussian
> blur, morphology filter, gamma, displacement map, just to name a few)
>  7. Hardware acceleration. Software rendering is nice, however, modern
> UIs are full of fancy stuff that require hardware acceleration.
>  8. Window and Event management library. With support of borderless and
> semi-transparent windows + good support of touchpad.
>  9. Custom written "Glue" library that allows all components to work
> together. Since modern libs are implemented in C++ we would need to
> implement C wrapper and a lot of integration tests.
> 10. Make the whole beast cross platform.
> 
> 

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

Thanks for this analysis

I call it the reality principle
Who will pay for it?
How many engineers can community afford?
Do you know how much other systems invest in graphical frameworks?
It is not a science project, isn't it?
There is always a tension between what we can achieve and the goal.
Now give 10 M Euros and I have no problem with your vision.

Now can you reply to Ronie's email.

Stef



On Thu, 26 Jan 2017 23:45:17 +0100, Aliaksei Syrel   
wrote:



Hi

(My previous email was not a joke, I don't try to troll anyone. Let  
tolls do their job in other places)
Let's forget Moz2D for a moment :) Imagine that it does not exist. It  
was done just for fun and is even not in pharo repo.  
(https://github.com/syrel/Moz2D). We needed something that works >and it  
was made investing just a few months of time of a single anonymous  
student during summer exams session and vacations.


I would like to start maybe one of the most important discussion that  
will influence Pharo and will dictate how system will look like in a few  
years. I invite everyone to join this discussion, >especially board and  
consortium members. Because here is where business starts.


There are some real questions:
Do we need Bloc or Morphic2 or %name your favourite framework%?
How advanced and modern do you want it to be?
What technology stack do we want to use for our new graphical framework?
What platforms and operating systems do we want to support?
How flexible technology stack should be? (some parts may change in the  
future)

Who will pay for it?
How many engineers can community afford?
Do you know how much other systems invest in graphical frameworks?
It is not a science project, isn't it?
Let me first put my two cents in.

Low-level UI framework (without widgets) consists of multiple parts:
Vector graphics library to render shapes (fill, stroke, path builder,  
composition and blending operators)
Font service library (to support different font formats and collect  
information about local fonts installed in the system)
Text layout engine (this is where glyph positioning magic happens, link  
above too)
Text shaping engine (for high quality text rendering, to understand the  
problem => http://behdad.org/text/)
Complex script library (to support ligatures, split glyphs and other  
UTF8 stuff, remember  
https://github.com/minimaxir/big-list-of-naughty-strings)
Image processing library (for various image effects, like gaussian blur,  
morphology filter, gamma, displacement map, just to name a few)
Hardware acceleration. Software rendering is nice, however, modern UIs  
are full of fancy stuff that require hardware acceleration.
Window and Event management library. With support of borderless and  
semi-transparent windows + good support of touchpad.
Custom written "Glue" library that allows all components to work  
together. Since modern libs are implemented in C++ we would need to  
implement C wrapper and a lot of integration >tests.

Make the whole beast cross platform.

Did I miss something?

Here are some modern technologies commonly used for mentioned parts:
Skia, Direct2D, CoreGraphics, Cairo
Fontconfig, Freetype2
HarfBuzz
Pango, OpenType
Graphite2, FriBidi
Imagemagic, SVG filters libraries
Vulkan, OpenGL
wxWidgets, QT, GTK, SDL2
todo
todo
Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea!

Let's assume that we stop on Cairo + Pango. According to pango.com

The integration of Pango with Cairo (http://cairographics.org/)  
provides a complete solution with high quality text handling and  
graphics rendering.


According to the this potential technology stack we will have:
Cairo for vector graphics and rendering of basic shapes
Pango for text rendering
SDL2 for window and events management
What we will not get:
Support of filters; Cairo does not support gaussian blur. 3D  
transformations, we will not be able to not implement card flip  
animation. Never reach the same performance if using platform >native  
frameworks (e.g. Direct2D on windows). Cairo will not die, but there is  
zero progress.
Vulkan support. Never with cairo. Pure OpenGL too (try to compile  
cairo-gl on mac, good luck!) There is a way to compile it with quartz  
support. As of version 2.7.9, XQuartz does not >provide support for  
high-resolution Retina displays to X11 apps, which run in pixel-doubled  
mode on high-resolution displays.  
(https://bugs.freedesktop.org/show_bug.cgi?id=92777).
Borderless or transparent window with SDL2. Also, did you notice that  
sdl2 window turns black/white while resizing? There is no way to get a  
continuous window resize event with SDL2  
>(https://bugzilla.libsdl.org/show_bug.cgi?id=2077). The issue is that  
events stop firing while user is resizing a window because main thread  
is blocked. Bug is already 3 years >old. Indeed SDL2 is used for games,  
however how often do gamers resize game window?
Stateless API. Must have for a graphical framework like Bloc where  
canvas state is not

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Ronie Salgado]

Hi,

Vulkan support. Never with cairo. Pure OpenGL too (try to compile cairo-gl
> on mac, good luck!) There is a way to compile it with quartz support. As of
> version 2.7.9, *XQuartz does not provide support for high-resolution
> Retina displays to X11 apps*, which run in pixel-doubled mode on
> high-resolution displays. (https://bugs.freedesktop.org/
> show_bug.cgi?id=92777).

Do not rely on Vulkan for core libraries now. It is very green and it has
lot of issues. For making Woden 2 with Vulkan on Linux, I had to fix and
debug the Intel Vulkan driver myself. Anyway, Athens over Vulkan it is also
not a problem, because I did an (incomplete) Athens backend using Woden 2.
I have an abstraction for Vulkan(Linux and Windows, probably never
available on apple machines), Metal(OS X and iOS) and D3D 12 (Windows, XBox
One devkit). Right now I am working on getting Woden 2 working with Metal,
which only works on 64 bits mode.

Low-level UI framework (without widgets) consists of multiple parts:
>
>1. Vector graphics library to render shapes (fill, stroke, path
>builder, composition and blending operators)
>2. Font service library (to support different font formats and collect
>information about local fonts installed in the system)
>3. Text layout engine (this is where glyph positioning magic happens,
>link above too)
>4. Text shaping engine (for high quality text rendering, to understand
>the problem => http://behdad.org/text/)
>5. Complex script library (to support ligatures, split glyphs and
>other UTF8 stuff, remember https://github.com/mi
>nimaxir/big-list-of-naughty-strings
>)
>6. Image processing library (for various image effects, like gaussian
>blur, morphology filter, gamma, displacement map, just to name a few)
>7. Hardware acceleration. Software rendering is nice, however, modern
>UIs are full of fancy stuff that require hardware acceleration.
>8. Window and Event management library. With support of borderless and
>semi-transparent windows + good support of touchpad.
>9. Custom written "Glue" library that allows all components to work
>together. Since modern libs are implemented in C++ we would need to
>implement C wrapper and a lot of integration tests.
>10. Make the whole beast cross platform.
>
>
> Did I miss something?
>
You cannot have SVG style vectorial graphics and high performance graphics
in the same time. SVG style paths are really hard to implement, and they
cannot be implemented efficiently on hardware. Path filling and stroking
are global operations that are best implemented using a serial software
scanliner. GPUs are only able to rasterize points, lines, triangles and
quads (usually decomposed in triangles). The primitives supported by GPUs
only require local information, so they are very efficient to render.

I do not understand why are you trying to copy the whole web rendering
architecture, which is awful in terms of performance. I think that it is a
far better idea to design a 2D graphics API, with the basic rendering
primitives that are required for implementing a Widget toolkit, and then
leave the SVG style vectorial graphics for some very special cases, such as
drawing an actual SVG. This minimalistic graphics API could be implemented
using Athens in the first place, then porting to OpenGL 2.0 ES for getting
a performance boost, and then when there is a volunteer, it could be
implemented with whatever bleeding edge or platform specific graphics API
is available. The basics graphics primitives that I have in mind are the
following:

- Points
- Lines (with width or without it)
- Triangles
- Convex polygons

- Rounded rectangle
- Circle / Ellipses

- Render into a texture ( required for doing filtering)
- Textured primitive
- Some 2D filters, with the ability of making them optional

- Text/Glyph drawing

The graphics API should be explicit in terms that they could be two
different memory spaces (CPU memory vs dedicated GPU memory), and that
transferring resource such as textures can be very expensive. This kind of
2D graphics API could be also useful for developing 2D games using Pharo
and OSWindow, an area where I am bit interested because it is far easier
than a full 3D renderer.

The API could be made partially stateless by passing the full description
of how to render the primitives (colored or not, textured or not, 1 or 10
pixel wide lines, etc). It is impossible to make the API completely
stateless, because the framebuffer where the rendering is happening by
definition is not stateless ;)

Best regards,
Ronei

2017-01-26 20:36 GMT-03:00 Martin McClure :

> On 01/26/2017 02:45 PM, Aliaksei Syrel wrote:
> > There are some real questions:
> >
> >  1. Do we need Bloc or Morphic2 or %name your favourite framework%?
> >  2. How advanced and modern do you want it to be?
> >  3. What technology stack do we want to use for our new graphical
> 

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Martin McClure]

On 01/26/2017 02:45 PM, Aliaksei Syrel wrote:
> There are some real questions:
> 
>  1. Do we need Bloc or Morphic2 or %name your favourite framework%?
>  2. How advanced and modern do you want it to be?
>  3. What technology stack do we want to use for our new graphical framework?
>  4. What platforms and operating systems do we want to support?
>  5. How flexible technology stack should be? (some parts may change in
> the future)
>  6. Who will pay for it?
>  7. How many engineers can community afford?
>  8. Do you know how much other systems invest in graphical frameworks?
>  9. It is not a science project, isn't it?
> 

[...]

Thanks for the analysis, Alex. It sounds like using Moz2d saves a lot of
work...

-Martin

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi

*According to conclusion above, we will plan how to migrate to Cairo.*
We will need help with Pango.

Cheers,
Alex

On 26 January 2017 at 23:45, Aliaksei Syrel  wrote:

> Hi
>
> (My previous email was not a joke, I don't try to troll anyone. Let tolls
> do their job in other places)
> *Let's forget Moz2D for a moment :) Imagine that it does not exist. *It
> was done just for fun and is even not in pharo repo. (
> https://github.com/syrel/Moz2D). We needed something that works and it
> was made investing just a few months of time of a single anonymous student
> during summer exams session and vacations.
>
> I would like to start maybe one of the most important discussion that will
> influence Pharo and will dictate how system will look like in a few years.
> I invite everyone to join this discussion, especially board and consortium
> members. Because here is where business starts.
>
> There are some real questions:
>
>1. Do we need Bloc or Morphic2 or %name your favourite framework%?
>2. How advanced and modern do you want it to be?
>3. What technology stack do we want to use for our new graphical
>framework?
>4. What platforms and operating systems do we want to support?
>5. How flexible technology stack should be? (some parts may change in
>the future)
>6. Who will pay for it?
>7. How many engineers can community afford?
>8. Do you know how much other systems invest in graphical frameworks?
>9. It is not a science project, isn't it?
>
> Let me first put my two cents in.
>
> Low-level UI framework (without widgets) consists of multiple parts:
>
>1. Vector graphics library to render shapes (fill, stroke, path
>builder, composition and blending operators)
>2. Font service library (to support different font formats and collect
>information about local fonts installed in the system)
>3. Text layout engine (this is where glyph positioning magic happens,
>link above too)
>4. Text shaping engine (for high quality text rendering, to understand
>the problem => http://behdad.org/text/)
>5. Complex script library (to support ligatures, split glyphs and
>other UTF8 stuff, remember https://github.com/mi
>nimaxir/big-list-of-naughty-strings
>)
>6. Image processing library (for various image effects, like gaussian
>blur, morphology filter, gamma, displacement map, just to name a few)
>7. Hardware acceleration. Software rendering is nice, however, modern
>UIs are full of fancy stuff that require hardware acceleration.
>8. Window and Event management library. With support of borderless and
>semi-transparent windows + good support of touchpad.
>9. Custom written "Glue" library that allows all components to work
>together. Since modern libs are implemented in C++ we would need to
>implement C wrapper and a lot of integration tests.
>10. Make the whole beast cross platform.
>
>
> Did I miss something?
>
> Here are some modern technologies commonly used for mentioned parts:
>
>1. Skia, Direct2D, CoreGraphics, Cairo
>2. Fontconfig, Freetype2
>3. HarfBuzz
>4. Pango, OpenType
>5. Graphite2, FriBidi
>6. Imagemagic, SVG filters libraries
>7. Vulkan, OpenGL
>8. wxWidgets, QT, GTK, SDL2
>9. todo
>10. todo
>
> Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea!
>
> Let's assume that we stop on Cairo + Pango. According to pango.com
>
> The integration of Pango with Cairo (http://cairographics.org/) provides
>> a complete solution with high quality text handling and graphics rendering.
>
>
> According to the this potential technology stack we will have:
>
>- Cairo for vector graphics and rendering of basic shapes
>- Pango for text rendering
>- SDL2 for window and events management
>
> What we will not get:
>
>- Support of filters; Cairo does not support gaussian blur. 3D
>transformations, we will not be able to not implement card flip animation.
>Never reach the same performance if using platform native frameworks (e.g.
>Direct2D on windows). Cairo will not die, but there is zero progress.
>- Vulkan support. Never with cairo. Pure OpenGL too (try to compile
>cairo-gl on mac, good luck!) There is a way to compile it with quartz
>support. As of version 2.7.9, *XQuartz does not provide support for
>high-resolution Retina displays to X11 apps*, which run in
>pixel-doubled mode on high-resolution displays. (
>https://bugs.freedesktop.org/show_bug.cgi?id=92777
>).
>- Borderless or transparent window with SDL2. Also, did you notice
>that sdl2 window turns black/white while resizing? There is no way to get a
>continuous window resize event with SDL2 (https://bugzilla.libsdl.org/s
>how_bug.cgi?id=2077). The issue is that events stop firing while user
>is resizing a windo

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi

(My previous email was not a joke, I don't try to troll anyone. Let tolls
do their job in other places)
*Let's forget Moz2D for a moment :) Imagine that it does not exist. *It was
done just for fun and is even not in pharo repo. (
https://github.com/syrel/Moz2D). We needed something that works and it was
made investing just a few months of time of a single anonymous student
during summer exams session and vacations.

I would like to start maybe one of the most important discussion that will
influence Pharo and will dictate how system will look like in a few years.
I invite everyone to join this discussion, especially board and consortium
members. Because here is where business starts.

There are some real questions:

   1. Do we need Bloc or Morphic2 or %name your favourite framework%?
   2. How advanced and modern do you want it to be?
   3. What technology stack do we want to use for our new graphical
   framework?
   4. What platforms and operating systems do we want to support?
   5. How flexible technology stack should be? (some parts may change in
   the future)
   6. Who will pay for it?
   7. How many engineers can community afford?
   8. Do you know how much other systems invest in graphical frameworks?
   9. It is not a science project, isn't it?

Let me first put my two cents in.

Low-level UI framework (without widgets) consists of multiple parts:

   1. Vector graphics library to render shapes (fill, stroke, path builder,
   composition and blending operators)
   2. Font service library (to support different font formats and collect
   information about local fonts installed in the system)
   3. Text layout engine (this is where glyph positioning magic happens,
   link above too)
   4. Text shaping engine (for high quality text rendering, to understand
   the problem => http://behdad.org/text/)
   5. Complex script library (to support ligatures, split glyphs and other
   UTF8 stuff, remember https://github.com/minimaxir/big-list-of-naughty-st
   rings)
   6. Image processing library (for various image effects, like gaussian
   blur, morphology filter, gamma, displacement map, just to name a few)
   7. Hardware acceleration. Software rendering is nice, however, modern
   UIs are full of fancy stuff that require hardware acceleration.
   8. Window and Event management library. With support of borderless and
   semi-transparent windows + good support of touchpad.
   9. Custom written "Glue" library that allows all components to work
   together. Since modern libs are implemented in C++ we would need to
   implement C wrapper and a lot of integration tests.
   10. Make the whole beast cross platform.


Did I miss something?

Here are some modern technologies commonly used for mentioned parts:

   1. Skia, Direct2D, CoreGraphics, Cairo
   2. Fontconfig, Freetype2
   3. HarfBuzz
   4. Pango, OpenType
   5. Graphite2, FriBidi
   6. Imagemagic, SVG filters libraries
   7. Vulkan, OpenGL
   8. wxWidgets, QT, GTK, SDL2
   9. todo
   10. todo

Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea!

Let's assume that we stop on Cairo + Pango. According to pango.com

The integration of Pango with Cairo (http://cairographics.org/) provides a
> complete solution with high quality text handling and graphics rendering.


According to the this potential technology stack we will have:

   - Cairo for vector graphics and rendering of basic shapes
   - Pango for text rendering
   - SDL2 for window and events management

What we will not get:

   - Support of filters; Cairo does not support gaussian blur. 3D
   transformations, we will not be able to not implement card flip animation.
   Never reach the same performance if using platform native frameworks (e.g.
   Direct2D on windows). Cairo will not die, but there is zero progress.
   - Vulkan support. Never with cairo. Pure OpenGL too (try to compile
   cairo-gl on mac, good luck!) There is a way to compile it with quartz
   support. As of version 2.7.9, *XQuartz does not provide support for
   high-resolution Retina displays to X11 apps*, which run in pixel-doubled
   mode on high-resolution displays. (https://bugs.freedesktop.org/
   show_bug.cgi?id=92777).
   - Borderless or transparent window with SDL2. Also, did you notice that
   sdl2 window turns black/white while resizing? There is no way to get a
   continuous window resize event with SDL2 (https://bugzilla.libsdl.org/s
   how_bug.cgi?id=2077). The issue is that events stop firing while user is
   resizing a window because main thread is blocked. *Bug is already 3
   years old. *Indeed SDL2 is used for games, however how often do gamers
   resize game window?
   - Stateless API. Must have for a graphical framework like Bloc where
   canvas state is not shared between visual elements. It means that while
   rendering users must not clean the state of a canvas after every draw call.

Bloc is not my or Glenn's or Doru's personal property. We suggest, you
decide. It would be great if com

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

My last mail on that topic

Esteban told me that we should recompile the cairo lib with acceleration  
enabled.


Now probably Mozz2d is the coolest techno right now.
We read about Azure when Igor started to build athens. Athens was designed  
to make sure that

when Cairo dies we do not have to rewritte everything.

Stef



On Thu, 26 Jan 2017 22:55:25 +0100, p...@highoctane.be  
 wrote:



Moz2D looks pretty great and the stateless argument makes sense.

Furthermore there is an isolation layer.
Interesting reads:
https://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/

http://robert.ocallahan.org/2011/09/graphics-api-design.html

https://wiki.mozilla.org/Platform/GFX/Moz2D

https://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h

Having browser grade speed views in a OSWindow is enabling.

Cairo is not going to give us super speedy UIs, sorry, just check the  
demos we have in the image, they are sluggish.


Phil



On Thu, Jan 26, 2017 at 10:27 PM, stepharong  wrote:




Hi,

Then we will need Cairo + SDL2 (that does not work for us)


I do not get why SDL20 would not work for us while it is used by gaming  
engines. Are we that special?
We built interactive applications for Thales with complex event touch  
and now suddenly "it does not work for us" TM.
I have the impression that each time I see Bloc we need something more  
special (now this is Gtk)
To me it looks like it is a systematic "fuite en avant" with even more  
Mb consumption each time.
Personally I do not care of blur and effects, or color max filters.  
Right now you do not even have a single example of something that is  
not a littledemo.


Why we cannot have a tk/tcl or red-language like working system? I mean  
working now and not relyingon multiple MB of code extracted from an  
existing project?


+ Freetype2 (for fonts) + Graphite (glyphs shaping technology in order  
to use them within vector graphics engine) + cross platform OpenGL /  
Vulkan context/device provider for hardware >>>acceleration +  
implement Filters for effects (blur, lights, color matrix filters,  
etc...).


Without all those technologies bloc WILL progress, from 80's to 00's.  
Still decades behind :)


Well I would prefer to have something from the 00 working now that from  
2016 not working.
Because now what I will do is continuing to work on Morphic because  
this is what I have.You see I removed graphics from my future books.  
You probably do not care.In the future I will concentrate on anything  
else than graphics and widgets like that I will have no frustration.
Hacking the compiler finally should be a lot nicer.You see next week I  
go to visit alain and I will not discuss nor work on such topics like  
that no frustration.
Finally I will not comment anymore on Bloc anymore. I should not have. 
You do not seem to understand my point so I will shut up but years will  
pass before Bloc will be integrated in Pharo, becauseintegrated means  
maintained by us in case the guys behind bloc/brick get hired by  
anybody else on earth.


You seem to underestimate that part.
Ok you are super right and I'm super wrong.
Stef









--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

On Thu, 26 Jan 2017 22:36:47 +0100, Tudor Girba   
wrote:



Hi Stef,

There was a misunderstanding. Alex was just listing the need of  
underlying technologies for the features that Bloc already supports.


Let’s restart this conversation. He will send an explanatory email.


I understood it correctly.
I just took a maintenance cost evaluation position and to me this is not  
sustainable.


Stef

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[p...@highoctane.be]

Moz2D looks pretty great and the stateless argument makes sense.

Furthermore there is an isolation layer.

Interesting reads:

https://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/

http://robert.ocallahan.org/2011/09/graphics-api-design.html

https://wiki.mozilla.org/Platform/GFX/Moz2D

https://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h

Having browser grade speed views in a OSWindow is enabling.

Cairo is not going to give us super speedy UIs, sorry, just check the demos
we have in the image, they are sluggish.

Phil



On Thu, Jan 26, 2017 at 10:27 PM, stepharong  wrote:

>
>
> Hi,
>
> Then we will need Cairo + SDL2 (that does not work for us)
>
>
> I do not get why SDL20 would not work for us while it is used by gaming
> engines. Are we that special?
> We built interactive applications for Thales with complex event touch and
> now suddenly "it does not work for us" TM.
> I have the impression that each time I see Bloc we need something more
> special (now this is Gtk)
> To me it looks like it is a systematic "fuite en avant" with even more Mb
> consumption each time.
>
> Personally I do not care of blur and effects, or color max filters. Right
> now you do not even have a single example of something that is not a little
> demo.
>
> Why we cannot have a tk/tcl or red-language like working system? I mean
> working now and not relying
> on multiple MB of code extracted from an existing project?
>
> + Freetype2 (for fonts) + Graphite (glyphs shaping technology in order to
> use them within vector graphics engine) + cross platform OpenGL / Vulkan
> context/device provider for hardware acceleration + implement Filters for
> effects (blur, lights, color matrix filters, etc...).
>
> Without all those technologies bloc WILL progress, from 80's to 00's.
> Still decades behind :)
>
>
> Well I would prefer to have something from the 00 working now that from
> 2016 not working.
>
> Because now what I will do is continuing to work on Morphic because this
> is what I have.
> You see I removed graphics from my future books. You probably do not care.
> In the future I will concentrate on anything else than graphics and
> widgets like that I will have no frustration.
> Hacking the compiler finally should be a lot nicer.
> You see next week I go to visit alain and I will not discuss nor work on
> such topics like that no frustration.
>
> Finally I will not comment anymore on Bloc anymore. I should not have.
> You do not seem to understand my point so I will shut up but years will
> pass before Bloc will be integrated in Pharo, because
> integrated means maintained by us in case the guys behind bloc/brick get
> hired by anybody else on earth.
>
>
> You seem to underestimate that part.
> Ok you are super right and I'm super wrong.
>
> Stef
>
>
>
>

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi Stef,

There was a misunderstanding. Alex was just listing the need of underlying 
technologies for the features that Bloc already supports.

Let’s restart this conversation. He will send an explanatory email.

Cheers,
Doru

> On Jan 26, 2017, at 10:27 PM, stepharong  wrote:
> 
> 
> 
> Hi,
> 
> Then we will need Cairo + SDL2 (that does not work for us) 
> 
> I do not get why SDL20 would not work for us while it is used by gaming 
> engines. Are we that special?
> We built interactive applications for Thales with complex event touch and now 
> suddenly "it does not work for us" TM.
> I have the impression that each time I see Bloc we need something more 
> special (now this is Gtk)
> To me it looks like it is a systematic "fuite en avant" with even more Mb 
> consumption each time. 
> 
> Personally I do not care of blur and effects, or color max filters. Right now 
> you do not even have a single example of something that is not a little 
> demo.
> 
> Why we cannot have a tk/tcl or red-language like working system? I mean 
> working now and not relying 
> on multiple MB of code extracted from an existing project?
> 
> + Freetype2 (for fonts) + Graphite (glyphs shaping technology in order to use 
> them within vector graphics engine) + cross platform OpenGL / Vulkan 
> context/device provider for hardware acceleration + implement Filters for 
> effects (blur, lights, color matrix filters, etc...).
> 
> Without all those technologies bloc WILL progress, from 80's to 00's. Still 
> decades behind :)
> 
> Well I would prefer to have something from the 00 working now that from 2016 
> not working. 
> 
> Because now what I will do is continuing to work on Morphic because this is 
> what I have. 
> You see I removed graphics from my future books. You probably do not care. 
> In the future I will concentrate on anything else than graphics and widgets 
> like that I will have no frustration.
> Hacking the compiler finally should be a lot nicer. 
> You see next week I go to visit alain and I will not discuss nor work on such 
> topics like that no frustration. 
> 
> Finally I will not comment anymore on Bloc anymore. I should not have. 
> You do not seem to understand my point so I will shut up but years will pass 
> before Bloc will be integrated in Pharo, because 
> integrated means maintained by us in case the guys behind bloc/brick get 
> hired by anybody else on earth. 
> 
> 
> You seem to underestimate that part.
> Ok you are super right and I'm super wrong. 
> 
> Stef

--
www.tudorgirba.com
www.feenk.com

"Be rather willing to give than demanding to get."

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

Hi,

Then we will need Cairo + SDL2 (that does not work for us)


I do not get why SDL20 would not work for us while it is used by gaming  
engines. Are we that special?
We built interactive applications for Thales with complex event touch and  
now suddenly "it does not work for us" TM.
I have the impression that each time I see Bloc we need something more  
special (now this is Gtk)
To me it looks like it is a systematic "fuite en avant" with even more Mb  
consumption each time.


Personally I do not care of blur and effects, or color max filters. Right  
now you do not even have a single example of something that is not a little

demo.

Why we cannot have a tk/tcl or red-language like working system? I mean  
working now and not relying

on multiple MB of code extracted from an existing project?

+ Freetype2 (for fonts) + Graphite (glyphs shaping technology in order  
to use them within vector graphics engine) + cross platform OpenGL /  
Vulkan context/device provider for hardware >acceleration + implement  
Filters for effects (blur, lights, color matrix filters, etc...).


Without all those technologies bloc WILL progress, from 80's to 00's.  
Still decades behind :)


Well I would prefer to have something from the 00 working now that from  
2016 not working.


Because now what I will do is continuing to work on Morphic because this  
is what I have.

You see I removed graphics from my future books. You probably do not care.
In the future I will concentrate on anything else than graphics and  
widgets like that I will have no frustration.

Hacking the compiler finally should be a lot nicer.
You see next week I go to visit alain and I will not discuss nor work on  
such topics like that no frustration.


Finally I will not comment anymore on Bloc anymore. I should not have.
You do not seem to understand my point so I will shut up but years will  
pass before Bloc will be integrated in Pharo, because
integrated means maintained by us in case the guys behind bloc/brick get  
hired by anybody else on earth.



You seem to underestimate that part.
Ok you are super right and I'm super wrong.

Stef

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi Stef,

As explained before Brick is where the main focus will be next. I think that 
once the editor will be working, we should see more visible movement in that 
department.

Cheers,
Doru


> On Jan 26, 2017, at 8:39 PM, stepharong  wrote:
> 
> I think that instead of investigating gtk (yet another library to bind and 
> carry around),
> it would be smarter to have Sparta back-end using an accelerated Cairo + 
> pango.
> Why? Because
>   - For example Cairo will not disappear in the future (here you will 
> tell me that it does not have all the full
>   features I think that Bloc should deliver Brick first and focus on 
> this because else it will stay a nice
>   experiment.)
>   - We do not have bench with an accelerated compiled version so no idea 
> if this is good enough.
>   - Cairo is about 1.5 mb vs 20Mb and it is packaged.
> 
> I share the concerns of Esteban about the maintenance of such Mozz2d bundling 
> and he was pretty
> clear with me, he will not maintain it nor take any responsibility about 
> pharo using it.
> 
>   So having a Cairo Sparta back-end would be a smart move.
> Stef
> 
> 
> 
> 
> 
>> Hi,
>> 
>> Thank you for the intensive set of issues you raised during the Bloc 
>> presentation. I think it is worthwhile addressing them more thoroughly, so 
>> let me start with the issue that seemed to have caused the most worries: 
>> Sparta & Moz2D.
>> 
>> Please keep in mind that while I am involved to some extent in Bloc, the 
>> real credits for the current state go to Glenn and Alex.
>> 
>> Moz2D (https://github.com/mozilla/moz2d, 
>> https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and 
>> using it puts us on par with the rendering speed of a web browser, which is 
>> a significant added value over what we have now.
>> 
>> However, as it was noted, it does come with a cost due to the fact that it 
>> is not available as standalone with only the features we are interested in. 
>> The vector graphics part is actually buildable out of the box. However, the 
>> text support needs to be extracted out of Moz2D, and this is where the 
>> patching scripts are used. The patches are there only for compilation 
>> purposes and not for features and they are applied automatically. You can 
>> see it here:
>> https://github.com/syrel/Moz2D
>> 
>> Alex updated recently the Moz2D version and it worked without problems. Of 
>> course, future changes in Moz2D might imply changes in this script as well, 
>> and this implies that we will need to maintain that script. And we could 
>> imagine applying these patches on the trunk of Moz2D to see if they work, 
>> and we can also imagine engaging with the Moz2D owners to see if we can find 
>> a middle ground.
>> 
>> Now, let’s put this into perspective. We are currently using Athens and the 
>> Cairo backend. While Cairo is provided as a standalone library it has not 
>> seen significant advances since Mozzila shifted its focus towards Moz2D. So, 
>> sticking with it might not be an ideal strategy either.
>> 
>> Furthermore, just like Athens, Sparta is an abstraction that allows us to 
>> switch the underlying backend should we need to. Until now we did not find a 
>> cross-platform backend that is as advanced and complete as Moz2D, but there 
>> is no reason to think that none other will appear in the future. Skia is an 
>> alternative but it is only a vector graphic engine without text support, so 
>> using it would imply to have another library for the text support.
>> 
>> Sparta also comes with a reasonable set of tests that is aimed at testing 
>> the basic Moz2D functionality to make sure that the assumptions on top of 
>> which Sparta is built are correct.
>> 
>> All in all, I think that the current situation is not ideal, but there is 
>> already enough engineering in place to actually make it work. And I 
>> definitely think that the potential it opens is rather significant.
>> 
>> And, if more people look at the scripts, we might find even better and 
>> cheaper ways to express it.
>> 
>> Cheers,
>> Doru
>> 
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "We cannot reach the flow of things unless we let go."
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Using Opera's mail client: http://www.opera.com/mail/

--
www.tudorgirba.com
www.feenk.com

"Every now and then stop and ask yourself if the war you're fighting is the 
right one."

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi,

The mail from Alex is a bit cryptic. Alex, please send a more elaborate answer 
:).

Cheers,
Doru


> On Jan 26, 2017, at 9:10 PM, Aliaksei Syrel  wrote:
> 
> Hi,
> 
> Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for 
> fonts) + Graphite (glyphs shaping technology in order to use them within 
> vector graphics engine) + cross platform OpenGL / Vulkan context/device 
> provider for hardware acceleration + implement Filters for effects (blur, 
> lights, color matrix filters, etc...).
> 
> Without all those technologies bloc WILL progress, from 80's to 00's. Still 
> decades behind :)
> 
> Cheers
> 
> On Jan 26, 2017 20:40, "stepharong"  wrote:
> I think that instead of investigating gtk (yet another library to bind and 
> carry around),
> it would be smarter to have Sparta back-end using an accelerated Cairo + 
> pango.
> Why? Because
> - For example Cairo will not disappear in the future (here you will 
> tell me that it does not have all the full
> features I think that Bloc should deliver Brick first and focus 
> on this because else it will stay a nice
> experiment.)
> - We do not have bench with an accelerated compiled version so no 
> idea if this is good enough.
> - Cairo is about 1.5 mb vs 20Mb and it is packaged.
> 
> I share the concerns of Esteban about the maintenance of such Mozz2d bundling 
> and he was pretty
> clear with me, he will not maintain it nor take any responsibility about 
> pharo using it.
> 
> So having a Cairo Sparta back-end would be a smart move.
> Stef
> 
> 
> 
> 
> 
> Hi,
> 
> Thank you for the intensive set of issues you raised during the Bloc 
> presentation. I think it is worthwhile addressing them more thoroughly, so 
> let me start with the issue that seemed to have caused the most worries: 
> Sparta & Moz2D.
> 
> Please keep in mind that while I am involved to some extent in Bloc, the real 
> credits for the current state go to Glenn and Alex.
> 
> Moz2D (https://github.com/mozilla/moz2d, 
> https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and 
> using it puts us on par with the rendering speed of a web browser, which is a 
> significant added value over what we have now.
> 
> However, as it was noted, it does come with a cost due to the fact that it is 
> not available as standalone with only the features we are interested in. The 
> vector graphics part is actually buildable out of the box. However, the text 
> support needs to be extracted out of Moz2D, and this is where the patching 
> scripts are used. The patches are there only for compilation purposes and not 
> for features and they are applied automatically. You can see it here:
> https://github.com/syrel/Moz2D
> 
> Alex updated recently the Moz2D version and it worked without problems. Of 
> course, future changes in Moz2D might imply changes in this script as well, 
> and this implies that we will need to maintain that script. And we could 
> imagine applying these patches on the trunk of Moz2D to see if they work, and 
> we can also imagine engaging with the Moz2D owners to see if we can find a 
> middle ground.
> 
> Now, let’s put this into perspective. We are currently using Athens and the 
> Cairo backend. While Cairo is provided as a standalone library it has not 
> seen significant advances since Mozzila shifted its focus towards Moz2D. So, 
> sticking with it might not be an ideal strategy either.
> 
> Furthermore, just like Athens, Sparta is an abstraction that allows us to 
> switch the underlying backend should we need to. Until now we did not find a 
> cross-platform backend that is as advanced and complete as Moz2D, but there 
> is no reason to think that none other will appear in the future. Skia is an 
> alternative but it is only a vector graphic engine without text support, so 
> using it would imply to have another library for the text support.
> 
> Sparta also comes with a reasonable set of tests that is aimed at testing the 
> basic Moz2D functionality to make sure that the assumptions on top of which 
> Sparta is built are correct.
> 
> All in all, I think that the current situation is not ideal, but there is 
> already enough engineering in place to actually make it work. And I 
> definitely think that the potential it opens is rather significant.
> 
> And, if more people look at the scripts, we might find even better and 
> cheaper ways to express it.
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "We cannot reach the flow of things unless we let go."
> 
> 
> 
> 
> 
> 
> 
> -- 
> Using Opera's mail client: http://www.opera.com/mail/
> 

--
www.tudorgirba.com
www.feenk.com

"Every thing has its own flow."

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi,

Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for
fonts) + Graphite (glyphs shaping technology in order to use them within
vector graphics engine) + cross platform OpenGL / Vulkan context/device
provider for hardware acceleration + implement Filters for effects (blur,
lights, color matrix filters, etc...).

Without all those technologies bloc WILL progress, from 80's to 00's. Still
decades behind :)

Cheers

On Jan 26, 2017 20:40, "stepharong"  wrote:

> I think that instead of investigating gtk (yet another library to bind and
> carry around),
> it would be smarter to have Sparta back-end using an accelerated Cairo +
> pango.
> Why? Because
> - For example Cairo will not disappear in the future (here you
> will tell me that it does not have all the full
> features I think that Bloc should deliver Brick first and
> focus on this because else it will stay a nice
> experiment.)
> - We do not have bench with an accelerated compiled version so no
> idea if this is good enough.
> - Cairo is about 1.5 mb vs 20Mb and it is packaged.
>
> I share the concerns of Esteban about the maintenance of such Mozz2d
> bundling and he was pretty
> clear with me, he will not maintain it nor take any responsibility about
> pharo using it.
>
> So having a Cairo Sparta back-end would be a smart move.
> Stef
>
>
>
>
>
> Hi,
>>
>> Thank you for the intensive set of issues you raised during the Bloc
>> presentation. I think it is worthwhile addressing them more thoroughly, so
>> let me start with the issue that seemed to have caused the most worries:
>> Sparta & Moz2D.
>>
>> Please keep in mind that while I am involved to some extent in Bloc, the
>> real credits for the current state go to Glenn and Alex.
>>
>> Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/Platf
>> orm/GFX/Moz2D) offers an advanced backend and using it puts us on par
>> with the rendering speed of a web browser, which is a significant added
>> value over what we have now.
>>
>> However, as it was noted, it does come with a cost due to the fact that
>> it is not available as standalone with only the features we are interested
>> in. The vector graphics part is actually buildable out of the box. However,
>> the text support needs to be extracted out of Moz2D, and this is where the
>> patching scripts are used. The patches are there only for compilation
>> purposes and not for features and they are applied automatically. You can
>> see it here:
>> https://github.com/syrel/Moz2D
>>
>> Alex updated recently the Moz2D version and it worked without problems.
>> Of course, future changes in Moz2D might imply changes in this script as
>> well, and this implies that we will need to maintain that script. And we
>> could imagine applying these patches on the trunk of Moz2D to see if they
>> work, and we can also imagine engaging with the Moz2D owners to see if we
>> can find a middle ground.
>>
>> Now, let’s put this into perspective. We are currently using Athens and
>> the Cairo backend. While Cairo is provided as a standalone library it has
>> not seen significant advances since Mozzila shifted its focus towards
>> Moz2D. So, sticking with it might not be an ideal strategy either.
>>
>> Furthermore, just like Athens, Sparta is an abstraction that allows us to
>> switch the underlying backend should we need to. Until now we did not find
>> a cross-platform backend that is as advanced and complete as Moz2D, but
>> there is no reason to think that none other will appear in the future. Skia
>> is an alternative but it is only a vector graphic engine without text
>> support, so using it would imply to have another library for the text
>> support.
>>
>> Sparta also comes with a reasonable set of tests that is aimed at testing
>> the basic Moz2D functionality to make sure that the assumptions on top of
>> which Sparta is built are correct.
>>
>> All in all, I think that the current situation is not ideal, but there is
>> already enough engineering in place to actually make it work. And I
>> definitely think that the potential it opens is rather significant.
>>
>> And, if more people look at the scripts, we might find even better and
>> cheaper ways to express it.
>>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "We cannot reach the flow of things unless we let go."
>>
>>
>>
>>
>>
>>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

I think that instead of investigating gtk (yet another library to bind and  
carry around),
it would be smarter to have Sparta back-end using an accelerated Cairo +  
pango.

Why? Because
	- For example Cairo will not disappear in the future (here you will tell  
me that it does not have all the full
	features I think that Bloc should deliver Brick first and focus on  
this because else it will stay a nice

experiment.)
	- We do not have bench with an accelerated compiled version so no idea if  
this is good enough.

- Cairo is about 1.5 mb vs 20Mb and it is packaged.

I share the concerns of Esteban about the maintenance of such Mozz2d  
bundling and he was pretty
clear with me, he will not maintain it nor take any responsibility about  
pharo using it.


So having a Cairo Sparta back-end would be a smart move.
Stef






Hi,

Thank you for the intensive set of issues you raised during the Bloc  
presentation. I think it is worthwhile addressing them more thoroughly,  
so let me start with the issue that seemed to have caused the most  
worries: Sparta & Moz2D.


Please keep in mind that while I am involved to some extent in Bloc, the  
real credits for the current state go to Glenn and Alex.


Moz2D (https://github.com/mozilla/moz2d,  
https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend  
and using it puts us on par with the rendering speed of a web browser,  
which is a significant added value over what we have now.


However, as it was noted, it does come with a cost due to the fact that  
it is not available as standalone with only the features we are  
interested in. The vector graphics part is actually buildable out of the  
box. However, the text support needs to be extracted out of Moz2D, and  
this is where the patching scripts are used. The patches are there only  
for compilation purposes and not for features and they are applied  
automatically. You can see it here:

https://github.com/syrel/Moz2D

Alex updated recently the Moz2D version and it worked without problems.  
Of course, future changes in Moz2D might imply changes in this script as  
well, and this implies that we will need to maintain that script. And we  
could imagine applying these patches on the trunk of Moz2D to see if  
they work, and we can also imagine engaging with the Moz2D owners to see  
if we can find a middle ground.


Now, let’s put this into perspective. We are currently using Athens and  
the Cairo backend. While Cairo is provided as a standalone library it  
has not seen significant advances since Mozzila shifted its focus  
towards Moz2D. So, sticking with it might not be an ideal strategy  
either.


Furthermore, just like Athens, Sparta is an abstraction that allows us  
to switch the underlying backend should we need to. Until now we did not  
find a cross-platform backend that is as advanced and complete as Moz2D,  
but there is no reason to think that none other will appear in the  
future. Skia is an alternative but it is only a vector graphic engine  
without text support, so using it would imply to have another library  
for the text support.


Sparta also comes with a reasonable set of tests that is aimed at  
testing the basic Moz2D functionality to make sure that the assumptions  
on top of which Sparta is built are correct.


All in all, I think that the current situation is not ideal, but there  
is already enough engineering in place to actually make it work. And I  
definitely think that the potential it opens is rather significant.


And, if more people look at the scripts, we might find even better and  
cheaper ways to express it.


Cheers,
Doru


--
www.tudorgirba.com
www.feenk.com

"We cannot reach the flow of things unless we let go."








--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi,

Yes, Sparta is independent from Athens. We actually started originally from 
Athens with a few modifications, but that soon proved to not be feasible 
because Athens also has to accommodate Morphic while Bloc is being developed.

Sparta has a similar structure and intent as Athens, but it differs in some 
essential ways:
- it has local coordinates.
- it offers clipping based on arbitrary shape, not only rectangle.
- it is for the most part stateless which makes it more suitable for composing 
independent visual pieces. This one in particular influences the public API.

About engaging the Moz2D community, we can work on that.

Cheers,
Doru


> On Jan 25, 2017, at 1:52 PM, Guillermo Polito  
> wrote:
> 
> Hi Doru,
> 
> First, I understand the effort you all made to make this big piece of work. I 
> have however some questions that probably you can help with:
> 
> 1) I understand Sparta is a library completely independent from Athens. But I 
> also understand that they follow the same reasoning and general design (a 
> general API to deal with 2D vectorial graphics with pluggable backends).
>   - What are the differences between sparta and athens then? This is really 
> unclear to me. Are there differences in the API? in the internal backend 
> requirements?
>   - In case there are many differences, What are the reasons that made you 
> implement a complete new library and not just extend the existing one 
> (Athens)?  
>   - or even, just make a moz2d backend for athens?
> 
> 2) About moz2d. I understand how the build process you use works. But it 
> looks a bit fragile. You mention engaging the mozilla people. I think this is 
> really important,
>   - either they could propose an alternative solution to what you're doing
>   - or, if you contribute back your patches to mozilla (which I think you 
> should), this will make your process depend less on custom-made patches
>   - besides, creating a link between the two communities is probably worth 
> it: people in mozilla may consider how their changes impact their users.
> 
> Guille
> 
> On Wed, Jan 25, 2017 at 12:41 PM, Tudor Girba  wrote:
> Hi,
> 
> Thank you for the intensive set of issues you raised during the Bloc 
> presentation. I think it is worthwhile addressing them more thoroughly, so 
> let me start with the issue that seemed to have caused the most worries: 
> Sparta & Moz2D.
> 
> Please keep in mind that while I am involved to some extent in Bloc, the real 
> credits for the current state go to Glenn and Alex.
> 
> Moz2D (https://github.com/mozilla/moz2d, 
> https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and 
> using it puts us on par with the rendering speed of a web browser, which is a 
> significant added value over what we have now.
> 
> However, as it was noted, it does come with a cost due to the fact that it is 
> not available as standalone with only the features we are interested in. The 
> vector graphics part is actually buildable out of the box. However, the text 
> support needs to be extracted out of Moz2D, and this is where the patching 
> scripts are used. The patches are there only for compilation purposes and not 
> for features and they are applied automatically. You can see it here:
> https://github.com/syrel/Moz2D
> 
> Alex updated recently the Moz2D version and it worked without problems. Of 
> course, future changes in Moz2D might imply changes in this script as well, 
> and this implies that we will need to maintain that script. And we could 
> imagine applying these patches on the trunk of Moz2D to see if they work, and 
> we can also imagine engaging with the Moz2D owners to see if we can find a 
> middle ground.
> 
> Now, let’s put this into perspective. We are currently using Athens and the 
> Cairo backend. While Cairo is provided as a standalone library it has not 
> seen significant advances since Mozzila shifted its focus towards Moz2D. So, 
> sticking with it might not be an ideal strategy either.
> 
> Furthermore, just like Athens, Sparta is an abstraction that allows us to 
> switch the underlying backend should we need to. Until now we did not find a 
> cross-platform backend that is as advanced and complete as Moz2D, but there 
> is no reason to think that none other will appear in the future. Skia is an 
> alternative but it is only a vector graphic engine without text support, so 
> using it would imply to have another library for the text support.
> 
> Sparta also comes with a reasonable set of tests that is aimed at testing the 
> basic Moz2D functionality to make sure that the assumptions on top of which 
> Sparta is built are correct.
> 
> All in all, I think that the current situation is not ideal, but there is 
> already enough engineering in place to actually make it work. And I 
> definitely think that the potential it opens is rather significant.
> 
> And, if more people look at the scripts, we might find even better and 
> cheaper ways to express it.
> 
> Cheers,
> D

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Guillermo Polito]

Hi Doru,

First, I understand the effort you all made to make this big piece of work.
I have however some questions that probably you can help with:

1) I understand Sparta is a library completely independent from Athens. But
I also understand that they follow the same reasoning and general design (a
general API to deal with 2D vectorial graphics with pluggable backends).
  - What are the differences between sparta and athens then? This is really
unclear to me. Are there differences in the API? in the internal backend
requirements?
  - In case there are many differences, What are the reasons that made you
implement a complete new library and not just extend the existing one
(Athens)?
  - or even, just make a moz2d backend for athens?

2) About moz2d. I understand how the build process you use works. But it
looks a bit fragile. You mention engaging the mozilla people. I think this
is really important,
  - either they could propose an alternative solution to what you're doing
  - or, if you contribute back your patches to mozilla (which I think you
should), this will make your process depend less on custom-made patches
  - besides, creating a link between the two communities is probably worth
it: people in mozilla may consider how their changes impact their users.

Guille

On Wed, Jan 25, 2017 at 12:41 PM, Tudor Girba  wrote:

> Hi,
>
> Thank you for the intensive set of issues you raised during the Bloc
> presentation. I think it is worthwhile addressing them more thoroughly, so
> let me start with the issue that seemed to have caused the most worries:
> Sparta & Moz2D.
>
> Please keep in mind that while I am involved to some extent in Bloc, the
> real credits for the current state go to Glenn and Alex.
>
> Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/
> Platform/GFX/Moz2D) offers an advanced backend and using it puts us on
> par with the rendering speed of a web browser, which is a significant added
> value over what we have now.
>
> However, as it was noted, it does come with a cost due to the fact that it
> is not available as standalone with only the features we are interested in.
> The vector graphics part is actually buildable out of the box. However, the
> text support needs to be extracted out of Moz2D, and this is where the
> patching scripts are used. The patches are there only for compilation
> purposes and not for features and they are applied automatically. You can
> see it here:
> https://github.com/syrel/Moz2D
>
> Alex updated recently the Moz2D version and it worked without problems. Of
> course, future changes in Moz2D might imply changes in this script as well,
> and this implies that we will need to maintain that script. And we could
> imagine applying these patches on the trunk of Moz2D to see if they work,
> and we can also imagine engaging with the Moz2D owners to see if we can
> find a middle ground.
>
> Now, let’s put this into perspective. We are currently using Athens and
> the Cairo backend. While Cairo is provided as a standalone library it has
> not seen significant advances since Mozzila shifted its focus towards
> Moz2D. So, sticking with it might not be an ideal strategy either.
>
> Furthermore, just like Athens, Sparta is an abstraction that allows us to
> switch the underlying backend should we need to. Until now we did not find
> a cross-platform backend that is as advanced and complete as Moz2D, but
> there is no reason to think that none other will appear in the future. Skia
> is an alternative but it is only a vector graphic engine without text
> support, so using it would imply to have another library for the text
> support.
>
> Sparta also comes with a reasonable set of tests that is aimed at testing
> the basic Moz2D functionality to make sure that the assumptions on top of
> which Sparta is built are correct.
>
> All in all, I think that the current situation is not ideal, but there is
> already enough engineering in place to actually make it work. And I
> definitely think that the potential it opens is rather significant.
>
> And, if more people look at the scripts, we might find even better and
> cheaper ways to express it.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "We cannot reach the flow of things unless we let go."
>
>
>
>
>
>

[Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi,

Thank you for the intensive set of issues you raised during the Bloc 
presentation. I think it is worthwhile addressing them more thoroughly, so let 
me start with the issue that seemed to have caused the most worries: Sparta & 
Moz2D.

Please keep in mind that while I am involved to some extent in Bloc, the real 
credits for the current state go to Glenn and Alex.

Moz2D (https://github.com/mozilla/moz2d, 
https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and 
using it puts us on par with the rendering speed of a web browser, which is a 
significant added value over what we have now.

However, as it was noted, it does come with a cost due to the fact that it is 
not available as standalone with only the features we are interested in. The 
vector graphics part is actually buildable out of the box. However, the text 
support needs to be extracted out of Moz2D, and this is where the patching 
scripts are used. The patches are there only for compilation purposes and not 
for features and they are applied automatically. You can see it here:
https://github.com/syrel/Moz2D

Alex updated recently the Moz2D version and it worked without problems. Of 
course, future changes in Moz2D might imply changes in this script as well, and 
this implies that we will need to maintain that script. And we could imagine 
applying these patches on the trunk of Moz2D to see if they work, and we can 
also imagine engaging with the Moz2D owners to see if we can find a middle 
ground.

Now, let’s put this into perspective. We are currently using Athens and the 
Cairo backend. While Cairo is provided as a standalone library it has not seen 
significant advances since Mozzila shifted its focus towards Moz2D. So, 
sticking with it might not be an ideal strategy either.

Furthermore, just like Athens, Sparta is an abstraction that allows us to 
switch the underlying backend should we need to. Until now we did not find a 
cross-platform backend that is as advanced and complete as Moz2D, but there is 
no reason to think that none other will appear in the future. Skia is an 
alternative but it is only a vector graphic engine without text support, so 
using it would imply to have another library for the text support.

Sparta also comes with a reasonable set of tests that is aimed at testing the 
basic Moz2D functionality to make sure that the assumptions on top of which 
Sparta is built are correct.

All in all, I think that the current situation is not ideal, but there is 
already enough engineering in place to actually make it work. And I definitely 
think that the potential it opens is rather significant.

And, if more people look at the scripts, we might find even better and cheaper 
ways to express it.

Cheers,
Doru


--
www.tudorgirba.com
www.feenk.com

"We cannot reach the flow of things unless we let go."