Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using external buffer possible? #222

Open
ericlangedijk opened this issue Jun 20, 2024 · 9 comments
Open

using external buffer possible? #222

ericlangedijk opened this issue Jun 20, 2024 · 9 comments

Comments

@ericlangedijk
Copy link

Currently I am copying my own rgba into the buffer of the softbuffer-surface.
I was wondering if that could be faster. And if it would be possible that the softbuffer uses this external buffer as source.
I saw that in Windows the drawing is done with BitBlt (which I believe is hardware-accelerated) and also was wondering if StretchDIBits would be an option. The last one does not need a source-handle, but don't know if StretchDIBits is as optimized.

@ids1024
Copy link
Member

ids1024 commented Jun 20, 2024

Could your program be refactored to write into the softbuffer::Buffer instead of a separate buffer?

At least on some backends, that should perform better than any possible implementation that presents from just a &[u8] or &[u32]. Not sure about the performance of StretchDIBits, BitBlt, and such. (Other than that SDL uses BitBlt with a comment that when implemented it ended up being faster than trying to use DirectX.)

@ericlangedijk
Copy link
Author

Yes BitBlt is fast.
I was thinking about your suggestion as well.
I could probably rewrite my home-made Bitmap (with all kinds of draw functions) to write to a 'backend' instead of its own Vec<Rgba. Lot of work but doable.
It saves a copy of some megabytes each frame....

@notgull
Copy link
Member

notgull commented Jun 21, 2024

Many drawing interfaces have a way to render to a mutable byte slice. For instance in my own code I use tiny-skia::PixmapMut around the softbuffer buffer in order to render in software to the window.

@daxpedda
Copy link
Member

I would be in favor of such an addition, but I don't know the limitations of other backends.

For Web at least, it should be perfectly possible after we implement the pixel format API. However it is not possible with the atomics target feature, where its not possible at all to draw from Wasm memory to begin with.

@ericlangedijk
Copy link
Author

Yes I think for certain backends it will not be possible or handy. No clue about other systems.
On windows we have a u32 array which happily has exactly the same layout as my inner bitmap on which i perform all my (cpu) drawing logic buffer scaling and rendering.

@daxpedda
Copy link
Member

Maybe some platform-specific extensions would be more appropriate then.

@ids1024
Copy link
Member

ids1024 commented Jun 26, 2024

If you want to write something specifically for Windows and have some very specific requirements, you can also always just do that directly with windows-rs instead of using Softbuffer.

I guess it's an open design question in softbuffer to decide when to offer platform extensions vs suggest using platform APIs directly.

@notgull
Copy link
Member

notgull commented Jul 15, 2024

I guess it's an open design question in softbuffer to decide when to offer platform extensions vs suggest using platform APIs directly.

I would say this is definitely a case where platform extensions should not be used. The changes required for some platforms to use direct buffers would effectively require re-architecting the entire crate.

@ericlangedijk
Copy link
Author

A little update on this: I managed to refactor my drawing. Enabling a 'borrowed bitmap', borrowing the softbuffer pixels.
The result are quite ok! On a WIndows PC fullscreen (3840 x 2160) I get around 500 frames per second (including all game logic).
I scale my inner game bitmap (320x200) up to the softbuffer pixels (3200x2000) and then call the 'present' function. Great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants