Welcome, Guest. Please login or register.

Author Topic: Speed of icons and background loading on gfx card  (Read 4850 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: Speed of icons and background loading on gfx card
« on: November 12, 2005, 01:32:33 PM »
To speed up background images on 3.x on 680x0

1) make sure you choose a nice easy to decode format, eg IFF, PNG etc.

2) make sure that if your datatype supports dithering (such as warpdt datatypes), turn them off for 15/16 bit screens. It doesn't look as good but error diffusion dithering from 24-bit to 15/16-bit takes *ages*.

If you have a PPC card with OS3.9, both of these issues are mitigated somewhat as the 3.9 picture.datatype can use PPC to do the colour reduction/dither and many datatypes come in PPC flavours.

If you want backdrops to look good in 15/16 bit modes (without dithering by the picture datatype), you can take your original 24-bit image and dither it down to 15 or 16-bit in a paint package first and save it in a non lossy format. You can't beat precalculation ;-)
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: Speed of icons and background loading on gfx card
« Reply #1 on: November 13, 2005, 02:58:43 PM »
Are you sure your workbench is 24 bit deep? Most cards use 32-bits as the alignment allows for faster rendering.

That said, IFF should be fast to decode anyway. You could also try PPM if you have a suitable datatype, but the file will be very large (probably take longer to load than rendering will).
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: Speed of icons and background loading on gfx card
« Reply #2 on: November 13, 2005, 05:41:41 PM »
Quote

MarkAshley wrote:
Quote

Karlos wrote:
Are you sure your workbench is 24 bit deep? Most cards use 32-bits as the alignment allows for faster rendering.

According to ScreenMode Prefs it is set to "Voodoo: 1024x768 24bit BGR" and the slider is set to 16M colours (but is greyed but and thus not adjustable).


That sounds nasty, generally it is reported as 32-bit BGRA (or little endian 32-bit ARGB if you think about it). Anyway the point is, if you are using some sort of packed pixel mode that genuinely has 24 bits for each pixel (not 32) you can expect a performance hit for graphics operations. Generally you only need to use 24-bit modes like this if you are short of memory or you don't have the bandwidth to show a high refresh rate. Neither of these apply to the voodoo.

Perhaps your settings are awry, the voodoo I have handy always shows 32-bit BGRA
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: Speed of icons and background loading on gfx card
« Reply #3 on: November 13, 2005, 07:41:14 PM »
Quote

MarkAshley wrote:

@Karlos
I don't really understand what that means. Should it be using 24bit or 32bit? And should the BGRA bit be there or not?


Ok, I guess I should rephrase it a bit :-)

Your screenmode preferences / screenmode selectors should preferentially show 32-bit modes for voodoo rather than 24 bit ones. If it does, most probably, the 32-bit ones will be labelled as "32 bit BGRA".

If it definately says 24-bit BGR, you are likely using what is known as "packed pixel format", where every pixel uses exactly 3 bytes. These can be slower than the 32-bit modes because of alignment issues. 32-bit modes don't actually give you any more useable colour depth than 24-bit ones but it is usually the case that both hardware and software drawing is faster.

I am not sure where you will find it but there is likely a env variable somewhere that 'enables' the 24-bit modes instead (or maybe as well as) of the 32-bit ones. You'd ideally want to turn this off.

Whilst you are about it, there is another env variable that controls wether or not the 15/16-bit modes are 'PC' (little endian, basically) or not. The voodoo3 supports both formats and frankly there is little reason to use little endian 'PC' modes if you can use the big endian ones instead.

I don't actually remember what these env vars are off hand, but someone here might do :-)

Remember, God will kill a kitten for every little endian access on your amiga ;-)
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: Speed of icons and background loading on gfx card
« Reply #4 on: November 13, 2005, 08:21:51 PM »
Yes, it sounds like you got the 32-bit mode now. It uses 25% more video memory but the speed increase for graphics.library etc is more than worth it.

Scaling down icons may well help. For 3.x, however, nothing comes close to the speed of the original 4 colour icons (nasty as they are)
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show all replies
Re: Speed of icons and background loading on gfx card
« Reply #5 on: November 13, 2005, 09:06:39 PM »
Hmm, tricky. Not sure, I'd generally use iconian, but if it is crashing :-/

You might just go for a smaller icon set if you can find one. Some people have reported that the png icon patch is faster on their classic systems than colourmapped icons. The way the icons are rendered on screen likely has something to do with that, but there is also the png decode time to factor into it.

You could try it, just on some dummy folders full of junk files first - AFAIK converting an icon to png format is irreversible.
int p; // A