We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 5510 - simplify the scaling functions
Summary: simplify the scaling functions
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: HG 2.0
Hardware: All All
: P2 normal
Assignee: Sylvain
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-28 10:49 UTC by Sylvain
Modified: 2021-01-30 19:16 UTC (History)
0 users

See Also:


Attachments
test-case (13.53 KB, text/x-csrc)
2021-01-28 14:39 UTC, Sylvain
Details
image (45.87 KB, image/bmp)
2021-01-28 14:39 UTC, Sylvain
Details
test_scaler_nearest.c (2.41 KB, text/x-csrc)
2021-01-28 14:52 UTC, Sylvain
Details
test_blit.c (13.50 KB, text/x-csrc)
2021-01-28 14:58 UTC, Sylvain
Details
test_blit.c (13.50 KB, text/x-csrc)
2021-01-28 14:59 UTC, Sylvain
Details
test_scaler_nearest.c (5.44 KB, text/x-csrc)
2021-01-29 10:18 UTC, Sylvain
Details
test_scaler_nearest.c (6.03 KB, text/x-csrc)
2021-01-29 19:38 UTC, Sylvain
Details
test_scaler_nearest.c (6.41 KB, text/x-csrc)
2021-01-30 19:16 UTC, Sylvain
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvain 2021-01-28 10:49:16 UTC
The scaling nearest algorithm can be simplified, without changing outputs.

(change initially starting with: bug #3816)
Comment 1 Sylvain 2021-01-28 14:38:32 UTC
Simplifying the function
https://hg.libsdl.org/SDL/rev/6618a817d8d2
https://hg.libsdl.org/SDL/rev/1bc8f3acfcce


little improvement: 
eg: blit slow (activating it manually) with a basic copy:

SDL_BlitSlow: 
< INFO: Time  Avg:    4.61 ms  Avg Perf: 4608957 (min=4532672)
---
> INFO: Time  Avg:   4.174 ms  Avg Perf: 4174557 (min=4126734)


One scale function in SDL_blit_auto:
< INFO: Time  Avg:   7.856 ms  Avg Perf: 7857160 (min=7702752)
---
> INFO: Time  Avg:   6.998 ms  Avg Perf: 6995194 (min=6864477)
Comment 2 Sylvain 2021-01-28 14:39:14 UTC
Created attachment 4725 [details]
test-case

test case
Comment 3 Sylvain 2021-01-28 14:39:41 UTC
Created attachment 4726 [details]
image
Comment 4 Sylvain 2021-01-28 14:52:17 UTC
Created attachment 4727 [details]
test_scaler_nearest.c

other test-case:

From the diffs, it's not clear that both revisions are identical.
But scaling with nearest, is only about mapping a 'src' index for each 'dst' index.
So proving the diff revision, can be done by comparing both old and new mappings. Hence this test case.
- compute previous way to scale nearest
- and new way.
both give the same result (tested up to  'from 1..10000 to 1..10000')
Comment 5 Sylvain 2021-01-28 14:58:44 UTC
Created attachment 4728 [details]
test_blit.c

Update first test-case
Comment 6 Sylvain 2021-01-28 14:59:31 UTC
Created attachment 4729 [details]
test_blit.c

mark older test-case as obsolete
Comment 7 Sam Lantinga 2021-01-28 17:12:53 UTC
Looks good, go ahead and make this change.
Comment 9 Sam Lantinga 2021-01-29 01:07:57 UTC
It looks like this code doesn't support sizes > 65535. Can you verify?
Comment 10 Sylvain 2021-01-29 10:18:06 UTC
Created attachment 4733 [details]
test_scaler_nearest.c

Update test-case
Comment 11 Sylvain 2021-01-29 10:47:10 UTC
Yes, there are issues with large sizes ...
but issues are also present in the old code:

for instance, if you scale: 
[0 .. 32768] -> [0..32767]

it pulls wrong indexes,
dst[0] = src[0] (fine)
dst[32767] = src[0] (not ok!)


so the old code, works up to 32767, eg:
src_width == 32767 is working
but fails with src_width == 32768


the new code seems to works up to 65535, eg:
src_width == 65535 is working
but fails with src_width == 65536


I have updated the test-case to be more flexible.
(use CASE==5, set PROCESS_OLD/NEW, tweaks the value val of CASE==5)


I think the old code could also be fixed to work up to 65535
(should use some unsigned to the steps). no


But I think the best to now to add a check against scaling with w/h > 65535
Comment 12 Sylvain 2021-01-29 11:05:40 UTC
Adding checks: https://hg.libsdl.org/SDL/rev/79cb445a0635
Comment 13 Sylvain 2021-01-29 11:15:03 UTC
Maybe the restrictions only apply for the source surfaces. 
or can be less restrictive for the destination size.
but 65535 seems fair enough
Comment 14 Sam Lantinga 2021-01-29 16:45:26 UTC
Yes, we should only apply size restrictions where they are actually necessary.
Comment 15 Sylvain 2021-01-29 19:38:26 UTC
Created attachment 4734 [details]
test_scaler_nearest.c

update test-case

Ok, so it seems there is not need to add restriction on destination size,
because scaling remains coherent

https://hg.libsdl.org/SDL/rev/af7a34284f0a
Comment 16 Sylvain 2021-01-30 19:16:01 UTC
Created attachment 4739 [details]
test_scaler_nearest.c

I thought again about it and I am mistaken about the last check removed.
If the destination size w or h is too big, then the value are actually wrongs.
(increment is truncated and so the scale ratio isn't respected)

( https://hg.libsdl.org/SDL/rev/ce3e0c74b49a )

If somebody need it, it can probably improved by using some int64 at some place but it needs more check about the various implements nearest and linear
Comment 17 Sylvain 2021-01-30 19:16:26 UTC
marked as fixed