smiffy92
Posts: 2
Joined: Thu Mar 29, 2012 1:28 pm

Re: Screen tearing?

Thu Mar 29, 2012 1:43 pm

Hello,

Is the RP capable of non-tearing scrolling and screen updates ? I think this is a function of the gpu - to date I have not seen a satisfactory solution for this on modern PC's (this affects gui smoothness, games, movies etc).

My old commodore 64, arcade machines from the 80's, and games consoles all have this inherent ability but somehow PC manufacturers and programmers haven't realised this.

Cheers

mole125
Posts: 228
Joined: Tue Jan 10, 2012 2:01 pm

Re: Screen tearing?

Thu Mar 29, 2012 1:57 pm

I'm really not sure what you are asking. All the games and GUI work I've done seem to scroll and update perfectly smooth when it should do.  The only time it doesn't is when the cpu can't generate the new parts of the screen quick enough which all depends on how the display code of the application is written and how much is buffered.

hzrnbgy
Posts: 106
Joined: Mon Dec 26, 2011 10:55 pm

Re: Screen tearing?

Thu Mar 29, 2012 2:17 pm

enable V-sync in your application or game. You can do this on most DirectX games (windows) but im not quite sure how to do it in Linux

User avatar
jojopi
Posts: 3141
Joined: Tue Oct 11, 2011 8:38 pm

Re: Screen tearing?

Thu Mar 29, 2012 2:19 pm

smiffy92 said:

to date I have not seen a satisfactory solution for this on modern PC's (this affects gui smoothness, games, movies etc).
For video and 3D your hardware should synchronise frame changes to your monitor's refresh rate.  You may get frame stuttering under load, but if you see any tearing something is configured wrong.

In a 2D GUI, dragging windows and scrolling in a browser, it is much more difficult to get this right.  The modern trend is to implement everything using 3D hardware so that windows are textures mapped onto flat objects...

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25045
Joined: Sat Jul 30, 2011 7:41 pm

Re: Screen tearing?

Thu Mar 29, 2012 2:23 pm

In general the GPU sorts this out during video playback , camera viewfinders, 3D graphics etc. Usually by using double buffering and syncing output. I believe it can go a bit pear shaped, as said above, if the load is too high.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

smiffy92
Posts: 2
Joined: Thu Mar 29, 2012 1:28 pm

Re: Screen tearing?

Thu Mar 29, 2012 2:27 pm

Ah ok that sounds good -

hzrnbgy - Vsync has never perfectly worked for me in Windows, neither has double buffering - I always notice when the frame rate isn't running at at least a rock solid 50fps/hz (this is in the UK).

jojopi - Would this work for movies too?

User avatar
RaTTuS
Posts: 10532
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: Screen tearing?

Thu Mar 29, 2012 2:44 pm

Frame buffers,

you write to one while the other is being displayed
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

User avatar
Lob0426
Posts: 2198
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
Contact: Website

Re: Screen tearing?

Thu Mar 29, 2012 4:00 pm

I see tearing in this iPad2 somewhat regularly but very rarely see it, and I mean rarely, on my my i7 desktop. There other factors that come into play other than just processing power and GPU. Almost all tearing I see is with content coming from the Internet.
512MB version 2.0 as WordPress Server
Motorola Lapdock with Pi2B
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!

User avatar
RaTTuS
Posts: 10532
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: Screen tearing?

Fri Mar 30, 2012 7:56 am

are you sure you don't mean lag?
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

Phil Spiegel
Posts: 210
Joined: Tue Jan 17, 2012 8:17 am
Contact: Website

Re: Screen tearing?

Fri Mar 30, 2012 11:37 am

In BBC Micro /Archimedes/RiscPC days, some game programmers 'changed modes' partway down the screen display - requiring accurate/consistent timing.

In this way they could have lots of colours (and low resolution) in some areas, and high res mono text in others .... isn't Elite a great exponent of the art in this respect?

This of course worked because of the shared-memory mapping of the older systems.

PCs went for separate graphics memories ..and processors! once they did more than crude text.

No doubt information will be forthcoming on whether or how the equivalent result can be achieved with The Raspberry Pi - we know the diagram shows designated areas for Screen and Processor ... but how long before someone starts switching or using an alternative access route?

User avatar
gordon@drogon.net
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Screen tearing?

Fri Mar 30, 2012 12:02 pm

Phil Spiegel said:


In BBC Micro /Archimedes/RiscPC days, some game programmers 'changed modes' partway down the screen display - requiring accurate/consistent timing.

In this way they could have lots of colours (and low resolution) in some areas, and high res mono text in others .... isn't Elite a great exponent of the art in this respect?

This of course worked because of the shared-memory mapping of the older systems.

PCs went for separate graphics memories ..and processors! once they did more than crude text.

No doubt information will be forthcoming on whether or how the equivalent result can be achieved with The Raspberry Pi - we know the diagram shows designated areas for Screen and Processor ... but how long before someone starts switching or using an alternative access route?



Ugh. I certinaly hope not! We're not dealing with a little 8-bit micro here where you can peek and poke all over the system, but a multi-user, multi-tasking operating system that really doesn't like to have its hardware poked at by anything other than itself, or via well defined system calls.

There are well defined way to detect vertical refresh, and graphical libraries that support it, (SDL, OpenGL, etc. all have ways to handle it), so if your software uses the whole screen, and an existing library, then it can use a double-buffered technique and flip screens on the refresh to avoid 'tearing' effects. When did you last see screen tearing in TuxRacer? (which runs under Linux)

Changing mode during a scan was a very clever, but grossly crude hack in those olden days - all to do with trying to allow for a high-resolution screen in monochrome and a low-resolution panel in colour on a computer with very limited (memory) resources. The R-Pi (along with almost every other PC out there) has a high resolution screen and plenty of RAM for it, so just use all of it to it's best effect without resorting to these hacks. They're just not needed.

Gordon
--
Gordons projects: https://projects.drogon.net/

Phil Spiegel
Posts: 210
Joined: Tue Jan 17, 2012 8:17 am
Contact: Website

Re: Screen tearing?

Fri Mar 30, 2012 12:11 pm

I did say 'or equivalent '  8-)  .. whatever the 'modern' equivalent is, unless its to waste memory like windows.

I look forward to reading documentation telling me what graphics, to match BBC BASIC /RISCOS drawing commands I can use. I'm not a 'games player'

- flight sim being the only game I've bought and played in over 10 years -but that's modelling of the 'real world' - sort of, with the Healt&Safety aspect to extreme

My initial project is for far simpler screen displays monitoring trains passing.

User avatar
gordon@drogon.net
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Screen tearing?

Fri Mar 30, 2012 12:46 pm

Phil Spiegel said:


I did say 'or equivalent '  8-)  .. whatever the 'modern' equivalent is, unless its to waste memory like windows.

I look forward to reading documentation telling me what graphics, to match BBC BASIC /RISCOS drawing commands I can use. I'm not a 'games player'

- flight sim being the only game I've bought and played in over 10 years -but that's modelling of the 'real world' - sort of, with the Healt&Safety aspect to extreme

My initial project is for far simpler screen displays monitoring trains passing.



The screen "modes" have been posted before, but essentially the R-Pi will support almost any resolution that a modern montor will support, right up to 1920x1080 in full colour.

As for the graphics, that will be up to the application or programming language you pick for your applicaiton. How does it get inputs, how do you want to represent outputs?

So I hope this doesn't come as a shock to you when I say that there are no built-in graphics commands! There are no peek/poke/VDU/plot and line or *fx commands.

Unless you want to write really low-level code, then you need to use a program or libary to manage it all for you and (arguably) the easiest way to get pixels onto the screen is with the SDL library, but you can build on top of that with other things. My BASIC uses SDL, so in BASIC, I can

colour = Green

line (0,0, 100,100)

for example, and behind that is a C program doing the hard work, by using the SDL (Simple Direct media Layer) library which then interfaces to the hardware via the operating system (Linux) the SDL library really only provides me with a block of RAM that represents the screen - I have to draw that line, pixel by pixel in a piece of C... (Using Bressenhams algorithm) If you want to see some of my graphics commands, then click on: http://unicorn.drogon.net/rtb3.png

SDL is callable from many systems - I use C, but if you wanted to code in Python, then there is a Python library for it too.

But if you want to do "windows" then it gets somewhat more complex, but also at a higher level, so once you've got the thing initialised, then it boils down to "open window", then you dress it with icons, buttons, tabs and so on - more code to write, but the interface is also at a higher level.

And you could even use a web browser as your output device - so if you can read your inputs (trains passing by) from a PHP or Python program, then you could have those programs output HTML - then run a web server on the R-Pi, and a web browser and off you go. Advantage then is that you could see your captured data from anywhere in the world as long as you have an Internet connection into it. Web browser to Server is a very high level protocol indeed, but it's used rather a lot as it can be realtively easy to get something in a graphical form to allow user inputs to stuff running behind the scenes. If you want an example of using a web browser to view external sensors, then have a look at this: http://www.dartcom.co.uk/weath...../index.php (not my site, but a good example) or even (more approriate for you): http://www.landsendweather.info/ais (again, not one of my sites, but it's run by a friend)

So maybe start thinking at a little bit of higher level and not wory (too much) about wasting memory - at least for now!

G
--
Gordons projects: https://projects.drogon.net/

Return to “General discussion”