@Tuxedo

LoView typically always scales the images too, to fit the window, right? The scaling is done by picture.datatype I suppose so differences there could make the difference perhaps?

I know scaling down images in PicShow takes longer time than the loading itself (but the quality is good).

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Severin

Well...
Doing a JPEG DataType that supports AltiVec dont seems to me an hack or something so complex...

However seems that was really a picture.datatype issue the difference from MOS to AOS however since AltiiVec dont seems to made a real difference...
Looking at the test made with the WarpJPG DT...

@Deniil715

The LoView LoadTime was calculated only on Image/Anim loading time...all the time after that(rescale and display) wasnt calculated so no matter if the image was resized (with optional smooth that was disabled by default) or not...

Last edited by Tuxedo on 15-Dec-2010 at 07:59 PM.

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

Tonight I tried compiling WarpJPEG with the -maltivec and -mabi-altivec options, and unsurprisingly it made no measurable difference to JPEG decoding speed. Although those compiler options allow GCC to use Altivec registers during optimization, Altivec isn't actually used throughout and the uses are quite isolated (I checked with a disassembler). As I think I said before, to use Altivec to its full effect, C code has to be specifically written to make use of the Altivec extensions - you cannot rely on GCC to magically make plain C code faster using Altivec.

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@Severin

Quote:

Severin wrote: You will also have to consider that none of the current OS4 hardware has a G4 so Altivec support isn't going to happen, all the machines with G4's are over 5 years old now, if it doesn't support Altivec now it never will unless some 3rd party coder does a hack.

*cough*x1000*cough*

_________________
AlexC's free OS4 software collection

AmigaOne XE/X1000/X5000/UAE-PPC OS4 laptop/X-10 Home Automation

@Futaura

Thank you for you last PNG datatype update.

Last edited by Templario on 19-Feb-2011 at 11:46 PM.

@Futaura

Check out this page for details on GCC's auto-vectorization, and getting info from the compiler on what it has done. Like you said, the compiler only knows how to vectorize particular constructs.

EDIT: The advantage of using the auto-vectorization over inline assembly code, is that the same auto-vectorization will work on other architectures too, whereas the assembly will be specific to the SIMD unit of a specific processor. Assembly will give you more control though.

Hans

Last edited by Hans on 20-Feb-2011 at 12:20 AM.
Last edited by Hans on 19-Feb-2011 at 11:59 PM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Thanks for the link - I wasn't aware of the -ftree-vectorize option. Unfortunately, compiling with that option doesn't have any performance impact on the jpeglib either . Altivec code doesn't have to be written in assembler, btw - GCC has an extension that allows Altivec code to be written in C, although obviously hand-optimized assembly is likely to be faster.

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@Futaura

Well...
Thank you for your tests!
Under MOS however the speed difference wasnt so big since I think that also ther picture.datatype need some sort of optimizations...maybe somone from Hyperion or betatesters can tell us idf something was already done bout that?
However I think that AltiVec support was really needed since also(as sayd above) PA6T have it...and it have to be optimised at maximum(PA6T code) to have better performaces possible...
Let see whats happening in future...

Good Work!

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.