New modern Webrowser Quasar

	Bottom Previous Topic Next Topic
Register To Post

« 1 (2)

smarkusg

Re: New modern Webrowser Quasar

Posted on: 10/8 22:10 #21

Quite a regular

@LiveForIt @joerg @samo79 @K-L
If I may chime in on this discussion. For now, it looks like the program will be ported to AOS4 from the original code.
If the original version uses “ibfreetype + fontconfig,” then even if someone were doing this without AI, they wouldn't bother with it.
The priority is stable code, and then fine-tuning. Why create problems for yourself right from the start? There will definitely be time for that later.

samo79

Re: New modern Webrowser Quasar

Posted on: 10/9 3:22 #22

Home away from home

@smarkusg

Well, yeah you are right

msteed

Re: New modern Webrowser Quasar

Posted on: 10/9 6:22 #23

Just popping in

@Maijestro

Quote:

Native Intuition (no MUI)

I'd like to advocate for using MUI or ReAction, rather than native Intuition/GadTools, for the user interface. It's likely that AI can just as easily create the UI using native Intuition as using one of the GUI toolkits, so there's little advantage to the developer in the AI era.

But there are advantages to the user, who can customize the look of the UI using one of the toolkits, unlike native Intuition. And there are advantages to the system, since it's more memory efficient for several programs to share something like a toolbar class than it is for each program to roll their own using just native Intuition/GadTools gadgets.

yssing

Re: New modern Webrowser Quasar

Posted on: 10/9 6:34 #24

Just popping in

@Maijestro

Amazing!

Alien Air Attack

SAM440@733 mhz as main amiga.

joerg

Re: New modern Webrowser Quasar

Posted on: 10/9 14:57 #25

Home away from home

@samo79
Quote:

Yeah, fonts on your old Origyn Web Browser had also a nicer look, where we can found the source?

All of my AmigaOS 4.x parts were on the Pleyo OWB SVN.
That doesn't exist since several years anymore, but the author of the AROS OWB port who, unlike the MorphOS OWB developer, uploaded all of his changes to the Pleyo SVN as well may still have a copy of those sources.
I don't have the complete OWB sources anymore, all I have on backups are diffs of my latest changes to the OWN SVN, and the sources of my AmigaOS 3.9/m68k port which doesn't include the AmigaOS 4.x-only AmigaOS native font rendering functions: The bullet.library from AGFA Compugraphic used in AmigaOS 2.1-3.9 was way too limited compared to Detlef's AmigaOS 4.x outline font engine.

Antique

Re: New modern Webrowser Quasar

Posted on: 10/9 16:12 #26

Home away from home

@Maijestro

Wow. Looking good. This is a needed product for OS4.

X5000

Maijestro

Re: New modern Webrowser Quasar

Posted on: 10/9 20:30 #27

Just can't stay away

@joergQuote:

joerg wrote:@Maijestro
Quote:
Fonts via fontconfig, PROGDIR:Fonts/WkSans.ttf, plus SYS:Fonts
I guess libfreetype + fontconfig?
Why?

I implemented AmigaOS 4.x native font rendering in OWB nearly 20 years ago already and it was at least 10 times faster than using libfreetype2. All of it open source of course, in Pleyo's OWB SVN.

Yes: libfreetype + fontconfig + HarfBuzz + Cairo. That is the WebKit 2.50 text stack (same family as WebKitGTK), not a random extra.

Your OWB diskfont path was the right call for that engine. Quasar is not that WebKit. Layout, CSS, @font-face, WOFF/OTF, and complex scripts all go through FontPlatformData/FreeType and HarfBuzz. Page text is UTF-16 inside the engine; glyphs come from the TTF Unicode cmap. AmigaOS codesets / diskfont.library cannot be that backend without rewriting the font cache, glyph pages, and shaper.

Speed: diskfont can beat FreeType on a handful of Latin UI glyphs. A modern page is not that. Glyphs are cached; the cost is layout and script, not Bullet vs FT per letter. We still ship PROGDIR:Fonts/WkSans.ttf so it runs without a tuned SYS:Fonts set. fontconfig can index extra TTFs under PROGDIR (and SYS:Fonts when they are real TTF), it does not draw through diskfont.

So: native OS4 fonts stay a possible fallback for chrome later. They are not a drop-in replacement for the 2.50 web text path. I did look at the old OWB sources — different problem.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE

afxgroup

Re: New modern Webrowser Quasar

Posted on: 10/9 22:08 #28

Amigans Defender

Plus diskfont/ft2 has a lot of other s**t that I could explain but I prefer to avoid..

i'm really tired...

khayoz

Re: New modern Webrowser Quasar

Posted on: 10/9 22:38 #29

Quite a regular

Hello guys!

I´m in my not Mclaren timemachine or am I ?

1989-> A500, A600, A3000, A4000, A1200, CD32, µA1, PegII, A1XE, CDTV, Amy/416D79, A1X5000, Vampire 500 V2+, Vampire 600 V2, Amy-ITX, Denise ITX, Apollo V4SA, A1X5000/40 <-2026

Georg

Re: New modern Webrowser Quasar

Posted on: Yesterday 6:44 #30

Just popping in

@joergQuote:

I implemented AmigaOS 4.x native font rendering in OWB nearly 20 years ago already and it was at least 10 times faster than using libfreetype2.

I'm not sure what you mean with native font rendering. But you still used freetype2 because the ~native AOS4 font engine (bullet "standard") "ft2.library" is using freetype2. So freetype2 is used either way, either directly by app or indirectly through AOS font engine.

Quote:

All of it open source of course, in Pleyo's OWB SVN.

I have looked on old HD and I have some owb-1.9-src.tar.bz2 lying around. 25317487 bytes big.


.        4815 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCGlyphPageTreeNodeAmigaOS4.cpp

        17026 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCFontPlatformDataAmigaOS4.cpp

        10595 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCSimpleFontDataAmigaOS4.cpp

         4861 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCSimpleFontDataAmigaOS4.h

         4138 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCFontCacheAmigaOS4.cpp

         2527 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCFontCustomPlatformDataAmigaOS4.cpp

         3691 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCGlyphBufferAmigaOS4.h

        10269 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCFontAmigaOS4.cpp

         2152 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCFontCustomPlatformDataAmigaOS4.h

         3044 2010-08-14 17:36 owb-1.9-src/BAL/Fonts/WebCore/AmigaOS4/BCFontPlatformDataAmigaOS4.h


static void drawglyphs(GraphicsContext* context, const SimpleFontData* font, const GlyphBuffer& glyphBuffer,

                      int from, int numGlyphs, const FloatPoint& point, float height, float ascent,

                      uint32 penalpha, uint32 penr, uint32 peng, uint32 penb, int shadowx, int shadowy)

{

    GlyphBufferGlyph* glyphs = const_cast<GlyphBufferGlyph*>(glyphBuffer.glyphs(from));

    struct OutlineFont *face = font->m_platformData.m_face;

    uint32 ysize = font->m_platformData.m_size;



    int32 imagewidth = 0;

    uint32 onlyspaces = TRUE;

    for (int i = 0; i < numGlyphs; i++) {

        if (32 != glyphs[i])

            onlyspaces = FALSE;

        imagewidth += glyphBuffer.advanceAt(from + i);

    }



    if (onlyspaces)

       return;



    if (imagewidth <= 0)

        return;



    imagewidth += 2 * (ysize * amigaConfig.fontXDPI / 72);



    Vector<unsigned> *glyphRGBABuffer = new Vector<unsigned>(imagewidth * height);

    if (!glyphRGBABuffer)

        return;



    glyphRGBABuffer->fill(0);



    int32 offsetinimg = 0;

    uint32 shiftleft = 0;



    for (int i = 0; i < numGlyphs; i++) {

        if (32 == glyphs[i]) {

            offsetinimg += glyphBuffer.advanceAt(from + i);

            continue;

        }



        struct GlyphMap *glyph;



        if (IDiskfont->ESetInfo(&face->olf_EEngine,

                                OT_GlyphCode, glyphs[i],

                                TAG_END))

            continue; //do not handle error



        struct OutlineFont *curface = face;

        if (IDiskfont->EObtainInfo(&face->olf_EEngine,

                                   OT_GlyphMap8Bit, &glyph,

                                   TAG_END)) {

            uint32 ok = FALSE;



            if (amigaConfig.unicodeFace

             && !IDiskfont->ESetInfo(&amigaConfig.unicodeFace->olf_EEngine,

                                     OT_PointHeight, ysize << 16,

                                     OT_GlyphCode, glyphs[i],

                                     TAG_END)

             && !IDiskfont->EObtainInfo(&amigaConfig.unicodeFace->olf_EEngine,

                                        OT_GlyphMap8Bit, &glyph,

                                        TAG_END)) {

                curface = amigaConfig.unicodeFace;

                ok = TRUE;

            }



            if (!ok

             && !IDiskfont->ESetInfo(&face->olf_EEngine,

                                     OT_GlyphCode, 0xFFFD,

                                     TAG_END)

             && !IDiskfont->EObtainInfo(&face->olf_EEngine,

                                        OT_GlyphMap8Bit, &glyph,

                                        TAG_END))

                ok = TRUE;



            if (!ok

             && !IDiskfont->ESetInfo(&face->olf_EEngine,

                                     OT_GlyphCode, '?',

                                     TAG_END)

             && !IDiskfont->EObtainInfo(&face->olf_EEngine,

                                        OT_GlyphMap8Bit, &glyph,

                                        TAG_END))

                ok = TRUE;



            if (!ok)

                continue; //do not handle error

        }



        if (amigaConfig.fontKerning && i > 0)

            if (!IDiskfont->ESetInfo(&curface->olf_EEngine,

                                     OT_GlyphCode, glyphs[i -1],

                                     OT_GlyphCode2, glyphs[i],

                                     TAG_END)) {

                FIXED kern = 0;

                if (!IDiskfont->EObtainInfo(&curface->olf_EEngine,

                                            OT_TextKernPair, &kern,

                                            TAG_END))

                    if (kern)

                        offsetinimg -= (int)(kern / 65536.0 * ysize * amigaConfig.fontYDPI / 72);

            }



        uint32 left = glyph->glm_BlackLeft;

        uint32 top = glyph->glm_BlackTop;

        int32 width = glyph->glm_BlackWidth;

        int32 gheight = glyph->glm_BlackHeight;

        int32 x0 = glyph->glm_X0;

        int32 y0 = glyph->glm_Y0;

        uint32 modulo = glyph->glm_BMModulo;

        int32 imgoffsetx = -x0 + left;



        if (offsetinimg + imgoffsetx < 0) {

            if (0 == i) {

                shiftleft = -imgoffsetx;

                if (shiftleft > ysize) {

                    shiftleft = ysize;

                    imgoffsetx = -ysize;

                }

                offsetinimg = shiftleft;

            }

            else

                imgoffsetx = 0;

        }



        int32 imgoffsety = ascent - y0 + top;



        if (imgoffsety < 0)

            imgoffsety = 0;



        if (offsetinimg + imgoffsetx + width > imagewidth) {

            int32 signedwidth = imagewidth - offsetinimg - imgoffsetx;

            if (signedwidth < 0)

                signedwidth = 0;

            width = signedwidth;

        }



        if (imgoffsety + gheight > (int)height)

            gheight = height - imgoffsety;



        for (int32 y = 0; y < gheight ; y++) {

            uint32 top_mod_left = (y + top) * modulo + left;

            for (int32 x = 0; x < width; x++)

                if ((offsetinimg + imgoffsetx + x < imagewidth)

                 && (offsetinimg + imgoffsetx + x >= 0)) {

                    uint32 a = penalpha * glyph->glm_BitMap[top_mod_left + x] / 255;

                    if (a) {

                        uint32 oldARGB = (*glyphRGBABuffer)[(imgoffsety + y) * imagewidth + offsetinimg + imgoffsetx + x];

                        if (oldARGB)

                            a = std::max((oldARGB >> 24), a);

                        (*glyphRGBABuffer)[(imgoffsety + y) * imagewidth + offsetinimg + imgoffsetx + x] = (a << 24) | ((penr * a / 255) << 16) | ((peng * a / 255) << 8) | (penb * a / 255);

                    }

                }

        }



        offsetinimg += glyphBuffer.advanceAt(from + i);



        IDiskfont->EReleaseInfo(&curface->olf_EEngine, OT_GlyphMap8Bit, glyph, TAG_END);

    }



    cairo_surface_t *surface = cairo_image_surface_create_for_data((unsigned char *)glyphRGBABuffer->data(), CAIRO_FORMAT_ARGB32, imagewidth, height, imagewidth * 4);

    if (surface) {

        cairo_t* cr = context->platformContext();



        cairo_set_source_surface(cr, surface, point.x() - shiftleft + shadowx, point.y() - ascent + shadowy);

        cairo_paint(cr);



        cairo_surface_destroy(surface);

    }



    delete glyphRGBABuffer;

}

LiveForIt

Re: New modern Webrowser Quasar

Posted on: Yesterday 8:01 #31

Home away from home

@Georg

I think there i some memory to be saved if AmigaOS had a global font cache, but that's is different angle.. how many programs use the same font.. how many times is it duplicated in memory.

maybe if font is used so often maybe it can be unloaded.. and loaded when needed.. if you can track how often its rendered.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

Georg

Re: New modern Webrowser Quasar

Posted on: Yesterday 10:51 #32

Just popping in

Quote:

I have looked on old HD and I have some owb-1.9-src.tar.bz2 lying around. 25317487 bytes big.

It's MorphOS OWB:

http://fabportnawak.free.fr/owb/
http://fabportnawak.free.fr/owb/src/

joerg

Re: New modern Webrowser Quasar

Posted on: Yesterday 20:37 #33

Home away from home

@Georg
Quote:

I'm not sure what you mean with native font rendering. But you still used freetype2 because the ~native AOS4 font engine (bullet "standard") "ft2.library" is using freetype2. So freetype2 is used either way, either directly by app or indirectly through AOS font engine.

The AmigaOS 4.x ft2.library is based on libfreetype2, but Detlef added several improvements to it, especially glyph cache and sub-pixel rendering related, making ft2.library on graphics.library bitmaps much faster than using libfreetype2.(a|so) (+fontconfig, which is extremly slow) on cairo or SDL surfaces.
Both fontconfig and the AmigaOS 4.x TTF library need a disk cache, and creating it is very slow. The difference is that the AmigaOS 4.x method creates it when a new font is installed (using TypeManager), for a single font, while fontconfig (re)creates it for every software using it separately on it's first start and for all TTF fonts installed.

Maijestro

Re: New modern Webrowser Quasar

Posted on: Yesterday 20:57 #34

Just can't stay away

I don't want to get into a debate about which font system is the better choice for AmigaOS 4.1 and WebKit 2.50. Some of you are absolutely right in what you've written, but everything is still in development, and for now I'm doing it the way the code is designed. Optimization comes at the end, once the engine is stable enough. What you see here is simply what I have so far, a look at where development stands right now.

Edited by Maijestro on 2026/10/10 21:50:22

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE

kas1e

Re: New modern Webrowser Quasar

Posted on: Today 5:12 #35

Home away from home

@Maijestro
Looks good already ! Loading quite fast, even first run not that slow as expected to be. Thing which i noticed right from start : slow scrolling of content, but that can be optimized later (check sources of Odyssey on my github to see how scrolling done there). All that compositing/realoaction/clipping can be used, so it will be fine. And i noticed also that you only visit pure plain amiga sites, those are easy ones of course, what about youtube/googlemaps/heavy-pages ?:)

ps. what version of ppc-JIT you use with ? The one comes with latest WebKit by default ?

Join us to improve dopus5!
AmigaOS4 on youtube

Maijestro

Re: New modern Webrowser Quasar

Posted on: Today 7:19 #36

Just can't stay away

@kas1e

Quote:

kas1e wrote:@Maijestro
Looks good already ! Loading quite fast, even first run not that slow as expected to be. Thing which i noticed right from start : slow scrolling of content, but that can be optimized later (check sources of Odyssey on my github to see how scrolling done there). All that compositing/realoaction/clipping can be used, so it will be fine. And i noticed also that you only visit pure plain amiga sites, those are easy ones of course, what about youtube/googlemaps/heavy-pages ?:)

ps. what version of ppc-JIT you use with ? The one comes with latest WebKit by default ?

No, it's not something that ships with WebKit. Upstream WebKit dropped PowerPC JIT support a long time ago. JavaScriptCore only has JIT backends for x86-64, ARM64, ARMv7 and RISC-V now.

The PPC JIT in Quasar is a custom backend I'm writing for this port: a 32-bit big-endian PowerPC assembler plus a PPC backend for WebKit's offlineasm. Right now the native LLInt interpreter and the Baseline JIT (with inline caches) are running. DFG and the RegExp JIT are still off. That's the next step once Baseline is solid.

The biggest hurdle is still the JIT. It has now reached a point where it works fairly stably, but as you could read, it's still not 100% complete. That's why I've focused on it first, and that alone has taken plenty of time. We're still in the alpha phase, and heavy sites don't render yet. I've noticed the slow scrolling too. Thanks for the tip, I'll take a close look at your sources and do it the way Odyssey does.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE

samo79

Re: New modern Webrowser Quasar

Posted on: Today 10:59 #37

Home away from home

@Joerg & all

I found an old AROS code from 2012 that should contain your font code, link here: https://uploadnow.io/f/c11fq42

joerg

Re: New modern Webrowser Quasar

Posted on: Today 13:34 #38

Home away from home

@samo79
Thanks, but it's useless.
I completely forgot that current web browsers can't use AmigaOS 4.x diskfont/ft2 font rendering any more since they need colour outline font support, for example for emoji. Some use it for UI parts as well.

diskfont.library and ft2.library only support b/w fonts (8 bit alpha).

Register To Post	« 1 (2)
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )