Scaling cleanup: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
mNo edit summary |
||
Line 19: | Line 19: | ||
'''TODO:''' The third one is really ugly (and it is the only reason why we have the unnecessary complication of video-viewport) and should be removed | '''TODO:''' The third one is really ugly (and it is the only reason why we have the unnecessary complication of video-viewport) and should be removed | ||
[[Category: | [[Category:Deprecated]] | ||
Latest revision as of 20:33, 23 March 2023
Status
generally the strategy for creating the initial window should be like this (in all ports):
- first the optimal size of the canvas is calculated
- then, the window is created of the right size
- NO resize message is sent to the window at startup, since the window is already of the right size.
- Instead, a resize message is sent to the window only when there's a user action such as enabling double-size, dragging window edges etc
ports that work like this: SDL
Right now 3 sizing models are supported
- the canvas size is calculated, then the window fits the canvas. Used by most ports when HW scaling is off
- the canvas size is calculated, the window has an arbitrary width and height, the image is streched/squeezed. Used by most ports when HW scaling is on
- the canvas size is calculated, the window's aspect ratio fits the canvas', the window has an arbitrary width or height
- the canvas size is calculated, the window has an arbitrary width and height, a black border is added to the image if the window is too big or the image is cropped smartly if the window is too small. (was used by Xaw)
TODO: The third one is really ugly (and it is the only reason why we have the unnecessary complication of video-viewport) and should be removed