Trying latest version od Odyssey Web Browser and it feels faster. I can actually watch some html5 youtube videos. Thank you all and please keep updating it.
@kas1e Downaloaded latest Odyssey from github and when trying to compile/build I get:
...
[ 32%] Building CXX object Source/WebCore/CMakeFiles/webcore.dir/__/__/BAL/Image
Decoder/WebCore/WK/BCImageDecoderWK.cpp.obj
In file included from /amiga/Odyssey/odyssey-r155188-1.23/BAL/ImageDecoder/WebCore/WEBP/WK/BCWEBPImageDecoderWK.cpp:30:
/amiga/Odyssey/odyssey-r155188-1.23/build/generated_link/BAL/WEBPImageDecoder.h:36:10: fatal error: webp/decode.h: No such file or directory
#include "webp/decode.h"
^~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Source/WebCore/CMakeFiles/webcore.dir/build.make:13117: Source/WebCore/CMakeFiles/webcore.dir/__/__/BAL/ImageDecoder/WebCore/WEBP/WK/BCWEBPImageDecoderWK.cpp.obj] Error 1
make[2]: *** Se espera a que terminen otras tareas....
In file included from /amiga/Odyssey/odyssey-r155188-1.23/BAL/ImageDecoder/WebCore/WK/BCImageDecoderWK.cpp:37:
/amiga/Odyssey/odyssey-r155188-1.23/build/generated_link/BAL/WEBPImageDecoder.h:36:10: fatal error: webp/decode.h: No such file or directory
#include "webp/decode.h"
^~~~~~~~~~~~~~~
compilation terminated.
@Javier And you should update whole SDK dir, as there was updated curl, openssl, rtmp, freetype, xml2 and xslt and that webp, all new includes/libs are in SDK now on github, so both should be cloned.
@All Dont forget to update SDK all the time from github, i offten update it currently.
Atleast compared to usual crashes this one seems more identicable
Quote:
Crash log for task "Odyssey" Generated by GrimReaper 53.19 Crash occured in module kernel at address 0x0181653C Type of crash: DSI (Data Storage Interrupt) exception Alert number: 0x80000003
@Samo Probabaly that one which K-L got some times, so if it indeed just cairo itself, and not Odyssey's code, then updating cairo to newer version may help.
Yes possible, but don't know .. with the old version on os4depot i never had such kind of crash and i had checked/saved dozen of that logs .. first time i see this one is with this beta 2 Aniway, updating to new cairo will worth for sure, hope it helps solving this aswell
Yes possible, but don't know .. with the old version on os4depot i never had such kind of crash and i had checked/saved dozen of that logs .. first time i see this one is with this beta 2
As you can see in readme for beta2 all what was changed its enabling of webp, new spoof agents and new freetype/xml/xstl. The only thing which somehow may be related is new freetype. But then, is it worth to rollback on old one, because it maybe cause that issue ?
If that sort of bugs when-one-visit-some-site was always easy reproduced, that can be somehow at least consider to fix , but when its random..
Webkit is full of bugs that for sure, and all those 3d party libs full of memory leaks and all sort of bugs that for sure too (its enough to check changelogs of all those 3d party libs, to see how many memory leaks they fix , and probabaly how many they introduce). Updating one or another lib will always bring something new : good and bad.
And i am sure we have there lots of memory trashing issues which can manifest in different areas too. They just shifts once new library/code added/removed.
In other words, what can we do there ? If your cairo-crash is random, how can we fix it ?
We can hope updating to new Cairo will solve some issues (and bring new ones, of course !:) ). Maybe new cairo will works better with new freetype as well. But nothing else can be done from my side at least, as fixing webkit's code is out of my skills surely. Expectually when bugs is random.
As you can see in readme for beta2 all what was changed its enabling of webp,
Sorry i meant first beta
Quote:
The only thing which somehow may be related is new freetype. But then, is it worth to rollback on old one, because it maybe cause that issue ?
Of course it's not worth to :)
Quote:
In other words, what can we do there ? If your cairo-crash is random, how can we fix it ?
Yeah you right, that crashes are almost random and hard to trace, let's update to latest cairo then ! In end it can't be worse for sure but only better .. I read your sdk readme on repo and cairo along with fontconfig and curl that you already updated seems the only libs in need to adaptions, the others only need configure and make with no special amiga-changes :) atleasr If i understand correctly. the hard part remained is just updating to latest cairo :)
Oh, then there we swap from gcc 4.4.3 to 8.3.0. And that as we can see can bring issues which was hided by luck in 4.4.3 (like one Hans fix before with trashed "conf" part). Probably, we need at first clean all the warnings of the amiga-gui code (there are a looot of all sorts)
Quote:
the others only need configure and make with no special amiga-changes :) atleasr If i understand correctly. the hard part remained is just updating to latest cairo :)
To say truth the only "./configure;make" is png, jpg, xml2, xslt & webp. Other ones may need more work. For example sqlite , icu not pure "./conigure;make", but if i remember right no needs much special changes. And other ones in one or another way need more work.
Cairo itslef is easy to update (already do this), replacing pthreads on semaphores there easy. But then, new cairo to be build, request: new freetype (done), new pixman-1 (also done, easy as well), and new fontconfig.
And with new fontconfig is where real changes and issues may start. I already build latest version, already fix the parts i fix for older version, and it buggy and trash the memory. I hope it trash the memory because its buggy by itselfa, not the odyssye trash the memory :)
For example, it crashes when run from RAM, or can't load file when run from SFS, and even when i run it from NGFS, it have some garbage in some buffers.
So with that one i need to clean things up, and do more tests, then put it online if can't deal with myself, so other ones can help with, and only then beta3 , which we can test if new fontconfig will be ok , and after that new pixman/cairo for beta4. Then sqlite, icu, ffmpeg, etc.
Ok good plan, hope we can deal with them fast with no big obstacles, i'm very excited waiting for the new phase, ehm start updating to 1.25 core to say one :D
I already build 1.25 version week ago, but it bring me some hardcore bug on running in javascript. And that one seems not related to issues about js-endianes seems so.
That one need to be fixed together with other ones, but before go futher with 1.25, i need to update all the libraries for 1.23 port, and after it will be proved that all works ok with current odyssey, i can then reuse the same libraries for 1.25, and then, bug-hunting of bugs preventing it from running can be started. And then, all the gui-fixes and stuff can be merget into. And then, if all will go well, updating 1.25 core should be easer than 1.23 as deadwood make some work to make updating core a bit more easer (but not _that_ easer, as when i ask him if he can/want to do so, he say its not about money , but about luck of motivation to work on odyssey as it require some boring work and co. But that all to very later, if we ever will go till that).
Ok, look at this This is probably the same crash i had, but you wasn't able to understand because the few info provided Now i have highlighted the stacktrace tab and then grabbed it, hopefully this will give you more usefull info
@Samo Our beloved threaded curl :) That for later for sure then.
@All I tried to update libpng to the latest one, and while fixing odyssey code was easy (just one place), I have some strange issue: 2 animation-png-images stop working. I.e. render nothing, while files loads for sure (i can see it via snoopy)
One animation used for tab-animation when loading, and another one used on the top right side (that compas). They placed in the Resource/ dir of Odyssey and named "transferanim.png" and "transferanim_tab.png".
Via snoopy I can see that file surely opens fine, and loads. Just visually when the animation should start nothing visibly.
I think that maybe those 2 resources files need updating to be compliant with 1.6.x? I thinking at first that maybe those files are APNG, but seems nope, at least it didn't contain usual apng chunks...