Do picture channels need to be swapped after all in the webp decoder engine? In the png decoder code f.e., there's no line where it looks for the endianess like in webp. Maybe it is done elsewhere in the component in chage of the render. Cairo format seems to be "ARGB" form the decoder sources. Regards,
and b) remove the forced Google search when one types into the address field, or rather replace it with the search engine that is set to be the first entry in the Search engines list.
and
2) Could you remove the "automatic completion suggestion" when typing into the search field (on the top right)? This one is annoying as hell as my typing is faster than the suggestions PD menu and i end up with broken entries, because the "suggestion" tends to "eat" the first character i typed once the PD menu is gone again.
At the left side OWB R1 and at the right the same page opened with the newest R2 All works fine, just this R2 seems a little bit slower when scrolling, but i'm not 100% sure yet
@Samo If font start to be better, then seems fresher freetype library can do something about, which in end can probabaly take a bit more ms for rendering.
@Raziel Are you sure about needs to add more search engines by default, as users can add them too ?
And about "automatic completion suggestion" at top/right, yeah, some option to turn that crap off will be handy for sure :)
@Petrol Quote:
Do picture channels need to be swapped after all in the webp decoder engine?
As it was there, probabaly it have needs for, but need to check yep
But if some speed difference still, it's really tiny I wonder if somethings exits in term of web tools to test this in real number Aniway as you are updating all libs hopefully an updated/accelerated Cairo/Pixmen could solve everything and add more and more fun
@samo With Cairo updating not all that fancy : I sure can update to the latest version, but it will be not hardware accelerated.
The version which Fredrik has, have amiga-specific surface, and there where things hardware accelerated. But Odyssey, use "image surface" all over the places, so to support even tiny bit of acceleration, it needs to changes in Odyssey's code in all the place to switch from image surface to amiga surface, and maybe then it can give some benefits (but no one know how much).
Probabaly after updating all the libs, that stuff need to be considered (i.e. to try to replace in the odyssey image -surface on amiga-surface to be able to use fredrik's version).
Do picture channels need to be swapped after all in the webp decoder engine? In the png decoder code f.e., there's no line where it looks for the endianess like in webp. Maybe it is done elsewhere in the component in chage of the render. Cairo format seems to be "ARGB" form the decoder sources. Regards,
Tried firstly both versions of that output (for big/middle/little endians) - both suck.
Then as you remind that cairo format seems to be ARGB from decoder sources, then i just do:
-- Added bunch of new and up2date user agents to "spoof as". -- Enabled WebP support -- WebKit revision number is now presented in AboutBox too -- Recompiled with more up2date 3d party libraries: libFreeType2 2.10.1, libXML2 2.9.10, libXSLT 1.1.34 and libWebP 1.0.3
Understand, just do you know what is the current state of the salass libs ? I mean, is everything accelerated already in his implementation and if not everything accelerated yet, atleast does we have already some simple test of his implementation compared to a "plain" one ? As you say that OWB need to be rewrite in various area for Amiga surface, having a simple test could atleast suggest us if in end the work will worth or not
Understand, just do you know what is the current state of the salass libs ? I mean, is everything accelerated already in his implementation and if not everything accelerated yet, atleast does we have already some simple test of his implementation compared to a "plain" one ? As you say that OWB need to be rewrite in various area for Amiga surface, having a simple test could atleast suggest us if in end the work will worth or not
So " It is just solid coloured shapes though, and if you enable anti-alias only drawing of rectangles is h/w accelerated.".
But i do not know what it mean from Odyssey's side. I mean how much Odyssey use "anti-aliased drawing of rectangles" and "solid coloured shapes".
As for tests, he have on his github page and tests as well, all can be downloaded and compiled easy with supplied makefiles (i tried few days ago). And it have some tests too. But once i see that those tests are "too much have amigaos4 native code", i understand that i can't simply replace old cairo with his one.
If only we can redirect somehow image-surfaces to amiga-surfaces, without needs to rewrite odyssey's code
I guess it's too much to ask to make the Search engines list at least "sortable"? So, that one can drag the wanted entry to the top? Or some change to make an entry "default" so it gets used on a fresh start? Right now, the first entry will always be used on a fresh start of Odyssey.
Same goes for the "Spoof as..." setting, it always goes back to "Default Setting" on a fresh start...or do i have to save the settings somewhere?
Many thnaks for taking up this work. Already some nice small improvements. The font rendering is much better with this version. Much easier on my eyes.
I did notice that is the beta02 release the $Ver:: isn't set although the version in the about box is correct.
When I right click on Odyssey beta02 and select version it shows the old version: "Odyssey Web Browser 1.23 (12/25/2013)"
@kas1e Spoofing as iphone 13 works great with youtube. ;)
A "little thing" you should add that I find annoying is in the "Download Fonts" script in the Odyssey folder, everytime I make an fresh install and "install" Odyssey I run the Download Fonts script, and it always fail until I add --no-check-certificate.