Photoshop（或绘图程序）如何进行 blit？
我正准备在 Windows 中制作绘图应用程序。我只是想知道，绘图程序是否有一个锁定的内存位图，然后设置每个像素，然后位图传输？
我不明白 Photoshop 如何在不使用硬件加速的情况下移动整个图层而没有延迟或闪烁。另外，在像 Expression Design 这样的程序中，我可以拥有 200 个形状，并可以毫无延迟地一次性移动它们。我真的很想知道在没有 GPU 帮助的情况下如何做到这一点。
另外，我不认为超级高效的算法可以证明这一点？
I'm getting ready to make a drawing application in Windows. I'm just wondering, do drawing programs have a memory bitmap which they lock, then set each pixel, then blit?
I don't understand how Photoshop can move entire layers without lag or flicker without using hardware acceleration. Also in a program like Expression Design, I could have 200 shapes and move them around all at once with no lag. I'm really wondering how this can be done without GPU help.
Also, I don't think super efficient algorithms could justify that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
看看这个问题：
用 GDI+ 和 C++ 减少闪烁
你能做的就是不使用GPU进行DC绘图是为了减少闪烁。其他任何事情都取决于填充内存位图的速度。在这里您可以使用高效的算法、多线程以及任何您需要的东西。
Look at this question:
Reduce flicker with GDI+ and C++
All you can do about DC drawing without GPU is to reduce flickering. Anything else depends on the speed of filling your memory bitmap. And here you can use efficient algorithms, multithreading and whatever you need.
当然，现代 Photoshop 使用 GPU 加速（如果可用）。另一个可能的工具是 DMA。您可能还会发现阅读 GIMP 等现有程序的源代码很有帮助。
Certainly modern Photoshop uses GPU acceleration if available. Another possible tool is DMA. You may also find it helpful to read the source code of existing programs like GIMP.
双（或更多）缓冲是游戏中的实现方式，在显示“前”缓冲区时，我们将大量垃圾绘制到“后”缓冲区中。然后，当绘制完成时，缓冲区被交换（指针交换，而不是复制！），并且该过程在新的前缓冲区和后缓冲区中继续。
三重缓冲提供了另一个好处，因为您可以在下一帧完成时从现在开始绘制两帧，但不会在屏幕刷新中间强制进行缓冲区交换。许多游戏会在刷新过程中进行缓冲区交换，但有时您会在屏幕上将其视为可见的伪影（撕裂）。
无论如何，对于将位图绘制到窗口中的应用程序，如果您有一些“慢”操作，请在将显示版本呈现给渲染 API（例如 GDI）时将其放入未显示的缓冲区中。让系统软件处理所有花哨的更新。
Double (or more) buffering is the way it's done in games, where we're drawing a ton of crap into a "back" buffer while the "front" buffer is being displayed. Then when the draw is done, the buffers are swapped (a pointer swap, not copies!) and the process continues in the new front and back buffers.
Triple buffering offers another bonus, in that you can start drawing two-frames-from-now when next-frame is done, but without forcing a buffer swap in the middle of the screen refresh. Many games do the buffer swap in the middle of the refresh, but you can sometimes see it as visible artifacts (tearing) on the screen.
Anyway- for an app drawing bitmaps into a window, if you've got some "slow" operation, do it into a not-displayed buffer while presenting the displayed version to the rendering API, e.g. GDI. Let the system software handle all of the fancy updating.