Odyssey 1.23 progress: r5 RC2

@Jabirulo
Drats, i thinking in other way around by some reassson, that it will take jpeg and recode it to webp :) Yeah, decode from webp to image works for me too.

So also tried "cwebp" to convert from jpeg to webp : and it also converts fine.

Through by "fine" it mean it shows fine by webp_datatype. Maybe we need to try to show it through libwebp examples from C code, and if it will works, then it mean Odysseys's webp imagedecoder fail on big-endian

Do you know if on webp decoder source you pointed few post above our build uses/enables
QCMS_WEBP_COLOR_CORRECTION ?

'cos you can try build with it enabled and disbled and see if it changes something.

@jabirulo
Our one build with it disabled. Yeah, may try to enable it.

@jabirulo
That QCMS_WEBP_COLOR_CORRECTION, use qcms library + lcms library. Also Odysseys's code in those ifdefs didn't builds with includes from qcms, so probabaly it wasnt' working and wasn't used since some time.

So the feel is that this is faster than before (before= md5sum b6735a66396eb51add0498b65e2aebdb).

I loaded www.adom.de a couple of times in both browsers, new build was always 12 seconds and old 16 seconds at best (from hitting enter to "done" message). So it surely can be a lot faster.

@Thematic

Indeed. Using Odyssey a lot, I immediately felt an improvement regarding speed when rendering pages.

@Thematic,K-L
That good ! It can be partly because of GCC 8.x switch and partly because of newer curl.

@kas1e

Indeed, i for myself warned others about possible "placebo" effects about speed, but now 2 entire days of use passed with lot of site visited and revisited .. and yeah i can admit that the sensation of more speed seems not only a sensation ! ... also no sluggish nor slowdown at all when browsing .. everything seems working great !

@samo79 Wait, do you not have the Grim Reaper visits?

@Thematic

No crash, atleast for now ..

I find a sure way to the GR - which is still there with the new version - is to use the Show Unread feature on Amiga.org (requires being logged in permanently) and then click on the little "new" icons next to each one. It often results in a DSI, which can sometimes be ignored, sometimes not (and often it results in the CPU going to 100%). And once it has happened, none of the unread threads are shown any more, although I can still use the "new" icons from the forum overview.

Anybody else see this?

Apart from this, I agree that the new one is faster and probably also more stable. Thanks to everyone involved in getting the work rolling!

Best regards,

Niels

@nbache

After a moment, I only had two new messages, but clicking on these only worked as if intended.

@thread

Where are the temporary files going to ?

I think everything should be done in RAM since its 100x + faster.

Has anyone used RAD: RAM: combo ? just wondering speeds and data alignment.

@Kas1e

One of the usual crash I get with any version of Odyssey, without any know reason and in a random way.

https://amiga-ng.org/resources/CrashLo ... y_2020-03-05_21-12-39.txt

@K-L
While crash is null-pointer one, all the crashes where you see lot of "WEBCORE" in stacktrace mean bugs in webkit's core. This one through ends with cairo+pixman, so maybe using more fresher ones will help, but i doubt.

Dind't have reproducable site so i can try to build with fresh cairo+pixman to see if it helps ?

@kas1e

Nope, it's totally random. This time it crashed while opening AmigaWorld (but only this time).

@kas1e

Ok finally got the first one .. a bit strange as it wasnt happened loading a page or browsing internet .. but just when i selected the owb window (i was using another software)--- aniway it's a stop one that force me to reboot amigaos still works but the application freezed

-------------------
Crash log for task "Odyssey"
Generated by GrimReaper 53.19
Crash occured in module kernel at address 0x01848010
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003

Register dump:
GPR (General Purpose Registers):
0: 01847E88 53A4AE80 00000000 00000001 53A4AE88 53A4B178 53A4B178 53FF0000
8: 00000000 00000002 00000000 02030000 48424884 53C6DD7C 00000000 54C16D00
16: 536F4028 53A4B0E8 01A6DF74 53FF528C 5FFFAC00 53A4B180 00000000 8042545B
24: 8042D777 00000001 8042C008 00000001 80422DA9 804237F9 53A4AE88 5FFF9300


FPR (Floating Point Registers, NaN = Not a Number):
0: nan nan 9 nan
4: nan 0 0 0
8: 4.5036e+15 nan 378.5 128
12: 7.63399e-305 0 0 -0
16: 1.32625e-315 0 0 0
20: 0 0 0 1.61895e-319
24: 0 0 2.65249e-315 0
28: 0 1.35808e-312 1.3581e-312 -2.15904e-78

FPSCR (Floating Point Status and Control Register): 0xA2008100


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0002F030
Condition (cr) : 0x50736DA0
Instruction Pointer (ip) : 0x01848010
Xtended Exception (xer) : 0x018233AC
Count (ctr) : 0x00000000
Link (lr) : 0x00000000
DSI Status (dsisr) : 0x01842B34
Data Address (dar) : 0x00000000



680x0 emulated registers:
DATA: 5857158E 00000003 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 53A4B1B0
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x01848010 belongs to module "kernel" (HUNK/Kickstart)

Stack trace:
native kernel module kernel+0x00048010
native kernel module kernel+0x00047dc0
LIBS:muimaster.library:GroupDispatcher()+0x464 (section 1 @ 0x46ED0)
native kernel module intuition.library.kmod+0x00021448
native kernel module intuition.library.kmod+0x000215ec
native kernel module intuition.library.kmod+0x000218c8
native kernel module intuition.library.kmod+0x00009ee4
native kernel module intuition.library.kmod+0x0000a184
LIBS:mui/Title.mui:_Dispatcher()+0x1b1c (section 1 @ 0x72B8)
native kernel module intuition.library.kmod+0x00021448
native kernel module intuition.library.kmod+0x000215ec
native kernel module intuition.library.kmod+0x0000a2d8
native kernel module intuition.library.kmod+0x00009f8c
LIBS:muimaster.library:SendIMsgs()+0x22c (section 1 @ 0x7DED0)
LIBS:muimaster.library:m_Window_Input()+0xa7c (section 1 @ 0x83D58)
LIBS:muimaster.library:WindowDispatcher()+0xdc (section 1 @ 0x885F0)
native kernel module intuition.library.kmod+0x00021448
native kernel module intuition.library.kmod+0x000215ec
native kernel module intuition.library.kmod+0x0000a2ac
Odyssey:_ZL8dispatchP6IClassPmP4_Msg()+0x438 (section 1 @ 0x2EE54)
native kernel module intuition.library.kmod+0x00021448
native kernel module intuition.library.kmod+0x000215ec
native kernel module intuition.library.kmod+0x0000a3f4
LIBS:muimaster.library:m_Application_NewInput()+0x84c (section 1 @ 0x28898)
LIBS:muimaster.library:ApplicationDispatcher()+0xd34 (section 1 @ 0x2DCAC)
native kernel module intuition.library.kmod+0x00021448
native kernel module intuition.library.kmod+0x000215ec
native kernel module intuition.library.kmod+0x0000a2ac
Odyssey:_ZL8dispatchP6IClassPmP4_Msg()+0x128 (section 1 @ 0xF92C)
native kernel module intuition.library.kmod+0x00021448
native kernel module intuition.library.kmod+0x000215ec
native kernel module intuition.library.kmod+0x0000a3f4
native kernel module intuition.library.kmod+0x0000a034
Odyssey:_Z9main_loopv()+0x168 (section 1 @ 0x13A0)
Odyssey:main()+0x1f0 (section 1 @ 0x1680)
native kernel module newlib.library.kmod+0x000020ac
native kernel module newlib.library.kmod+0x00002d5c
native kernel module newlib.library.kmod+0x00002ef0
Odyssey:_start()+0x170 (section 1 @ 0x214)
native kernel module dos.library.kmod+0x000255c8
native kernel module kernel+0x0003e7b4
native kernel module kernel+0x0003e7fc

@samo79

That one surely mui or mui-code of odyssey. I catch the same kind of crash (also coming from title.mui) and report it to Thore few days ago:

http://muidev.de/ticket/428

Seeing crashlogs, it all seems about the same.

It would be nice if someone could try to reproduce the crash using the supplied binaries with debug symbols included. That way the crashlog contains file names and line numbers.

@Thore
Already got debug crashlog, but was in hurry to go, once will back (few hours) will upload it