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...
@Petrol Checked that ULONG thing you ask before edit your post : nope, that not it as well.
As for WritePixelArrayAlpha(), graphics.library didn't have such function, so it can't be mixed.
But yes, its all feels something about alpha/colors changes when we use png1.6 instead of 1.2. And it leave some artefacts like it works, just nothing visibly.
There one odyssey at bottom with old libpng (see compas animatino works) and one at top with new libpng (instead of compas, there just a dots). But images sure loads, i can see it from snoopy.
EDIT: I think what we see on video it just "fallback" mode. See in those files i point out :
// Fall back to builtin animation
if(!src || !stride)
{
src = (char *) &Throbber;
stride = THROBBER_WIDTH * sizeof(ULONG);
}
So maybe we not in if(data->surface) now by some reassons, and fallback to built in animation (those small dots). And "throbber.cpp" file looks very much as those dots i have now.
(re. my crashes with the Unread feature on Amiga.org)
Quote: @nbache
After a moment, I only had two new messages, but clicking on these only worked as if intended. Hmm, interesting.
This made me try it out under a clean "public" installation of 4.1FEu1, and there I couldn't reproduce it (so far). It seems it only happens under OS4 beta. I have seen it for a long time, though, so it's not anything that arrived with the latest beta components (nor with the new Odyssey release).
With the second beta, it looks like my crashes using the Unread/New buttons on Amiga.org is gone! At least I haven't seen it happen since I upgraded.
Also, it seems in general more stable and faster than ever.
Both sites have problem with latest r5 beta_02, but works fine with stable official version of odyssey .. i fear in end will be forced to revert a library
@samo79 Try to unpack beta02 to ram, and then retestest everything again.
Quote:
Both sites have problem with latest r5 beta_02, but works fine with stable official version of odyssey .. i fear in end will be forced to revert a library
All the libraries should be updated, because its the only way move forward, be it 1.25, or new core, or whatever else.
Try everything from RAM: , fresh unpacked beta02. Then if issue there, fresh unpack to RAM beta01 and try that one. You know how to test things i am sure :) And i shomehow sure you mess with spoofing options at night. And plz, at moment wait till other will read/help with PNG issues plz, as topic will be flooded.
@All About png issues with png-animation images when swapped from 1.2 to 1.6 its as i expect tomorrow: when we compile with 1.2, then we inside of "if(data->surface)". When compile with 1.6, then we have no data->surface there, and fallback to to builtin animation.
Now need to understand why. Interesting that it happens only with animation pngs, not with pure ones, all other pngs loads and shows fine.
I do search in whole odysseys code just on "if(data->surface)", to see if it used anywhere else and it used in 4 classes: 2 for animation (tabtransferanimclass.cpp and transferanimclass.cpp) and 2 for icons (faciconclass.cpp and iconclass.cpp). As icons in the tabs, and icons in the hotlinks are works, it mean that "data->surface" thing works with libpng1.6, just by some reassons fail for those 2 anim classes.
Any ideas ?:)
The things i change in the Odyssey's code to compile it with 1.6, its only there (see commented at end of 2 strings, that what i added for 1.6):
But then i even use the 1.6 way, and compile with 1.2png (and 1.2 includes, no 1.6 of course), and it also works. So if something to blame, its new png includes differences and/or classes itself.
EDIT2: i also checked today's webkit code and they use the same way for 1.6 build. It seems that issue can be inside of amiga-mui code, as png-decoder seems almost the same in today's webkit. At least in that png-decoder part.
Maybe something should be also changed in cairo parts of odyssey code ..
And when i compile with includes/lib from 1.2, then i go inside of "if(cairo_surface_status(data->surface) == CAIRO_STATUS_SUCCESS)". But when i compile with 1.6, then i go to "else", so fallback later in DEFMMETHOD(Draw) to default animation, as no data->surface of course.
By some reassons with 1.6 we have !=CAIRO_STATUS_SUCCESS. Maybe cairo_image_surface_create_from_png fail somehow
Edited by kas1e on 2020/3/15 11:18:12 Edited by kas1e on 2020/3/15 11:43:48 Edited by kas1e on 2020/3/15 11:46:19 Edited by kas1e on 2020/3/15 11:47:28
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
