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 <alex.sy...@gmail.com>
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 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 community could invest money and time in a
working and appropriate solution.
P.S. If we would not care, we would agree with you instantly and even
not bothered ourselves trying to spend time on finding cheap solution
for such a complex problem.
P.P.S Sorry for a long email :)
Cheers,
Alex
On 26 January 2017 at 21:10, Aliaksei Syrel <alex.sy...@gmail.com> 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" <stephar...@free.fr> 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/
--
Using Opera's mail client: http://www.opera.com/mail/