Sdl vs qt: scrolling

SDL Development
1

hi

i’m wondering why it is so difficult to get good scrolling on my old 166mhz
with sdlbut with a toolkit like qt or gtk it is simple and faster.
i’m using debian linux.

when i try to scroll a true color image with sdl it’s very slow and uses a lot
of cpu.
when i try this with qt or gtk i just create a frame bigger than the picture
and a scrollbar and it works in ‘realtime’ without using so many cpu.

and so in all the web-browsers. when i got a side with many pics on it, i
can scroll it in ‘realtime’.

why is that so?
i’m not very confirm in programming graphics, so that perhaps why i
don’t understand the problem.

thanx for help

mirko koenig

2

when i try to scroll a true color image with sdl it’s very slow and uses a lot
of cpu.

Under X11, SDL has to move a lot of data around which is slow, in
particularly across the bus to the video memory. Even so it isn’t too bad
if you are careful.

Since you did not show us any code that demonstrates your problem, we have
to guess what you are doing wrong. Maybe you are blitting between surfaces
that have different pixel formats? Or, perhaps you have unrealistic
expectations, such as wanting to scroll a 1280x1024x32bpp image at
85Hz? Use x11perf -shmput500 to see what you reasonably can expect from
your X server

3

In article <200105141258.OAA01929 at my.nada.kth.se>,
“Mattias Engdegard” wrote:

when i try to scroll a true color image with sdl it’s very slow and uses a lot
of cpu.

Since you did not show us any code that demonstrates your problem, we have
to guess what you are doing wrong.

ok. here’s some code.

#!/usr/local/bin/python

first test using pygame

import os
import pygame, pygame.font, pygame.image, pygame.mixer
from pygame.locals import *

pygame.init()

screen = pygame.display.set_mode((640, 480)) #, HWSURFACE|DOUBLEBUF )
pygame.display.set_caption(‘Aguilera Test’)

11383 caguilera130.jpg

it is 170x350 24-bit true color

pic = pygame.image.load(‘caguilera130.jpg’)

i = 0
for i in range( 10000 ):
######### scrolling ##############
rect = screen.blit( pic, (0,i) )
pygame.display.update( rect)

4
> 85Hz? Use x11perf -shmput500 to see what you reasonably can expect from > your X server

This is a new test to me :wink:

Can anyone point me to some documentation telling me how to interpret the stuff
this spits out ? ;-)On Mon, 14 May 2001, you wrote:

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

5

Should I trash my PC ? :slight_smile:

Sync time adjustment is 0.2150 msecs.

800 reps @   7.6268 msec (   131.0/sec): ShmPutImage 500x500 square
800 reps @   7.6425 msec (   131.0/sec): ShmPutImage 500x500 square
800 reps @   7.6664 msec (   130.0/sec): ShmPutImage 500x500 square
800 reps @   7.6477 msec (   131.0/sec): ShmPutImage 500x500 square
800 reps @   7.6278 msec (   131.0/sec): ShmPutImage 500x500 square

4000 trep @ 7.6422 msec ( 131.0/sec): ShmPutImage 500x500 square

Bye.On 14 May 2001 12:44:27 -0700, Samuel Hart wrote:

On Mon, 14 May 2001, you wrote:

85Hz? Use x11perf -shmput500 to see what you reasonably can expect from
your X server

This is a new test to me :wink:

Can anyone point me to some documentation telling me how to interpret the stuff
this spits out ? :wink:

6

Should I trash my PC ? :slight_smile:

everybody should

4000 trep @ 7.6422 msec ( 131.0/sec): ShmPutImage 500x500 square

you must tell us what screen depth you used for this to mean anything.
If it’s 16bpp, then your update runs at about 5005002131.0 = 65 MB/s,
which is moderately impressive but not entirely worthless. It would also
mean that for a 800x600 screen size you could expect one update to
consume 7.6422 * (800600) / (500 * 500) == 14.67 ms, or 68/s

These sort of estimates are useful to see how much time you have to play
with for each frame and what frame rates you can expect to achieve
under X11

7

Should I trash my PC ? :slight_smile:

everybody should

You’re right :slight_smile:

4000 trep @ 7.6422 msec ( 131.0/sec): ShmPutImage 500x500 square

you must tell us what screen depth you used for this to mean anything.
If it’s 16bpp, then your update runs at about 5005002131.0 = 65 MB/s,
which is moderately impressive but not entirely worthless. It would also
mean that for a 800x600 screen size you could expect one update to
consume 7.6422 * (800600) / (500 * 500) == 14.67 ms, or 68/s

These sort of estimates are useful to see how much time you have to play
with for each frame and what frame rates you can expect to achieve
under X11

Yup 1024x768x16 on a p2 300 . I can consider myself happy with that
result.

Thanks for your usefull tips.
G.GabrieleOn 15 May 2001 11:57:08 +0200, Mattias Engdegard wrote: