Can we use bitblt in linux? I saw a bitblt documentation which states that bitblt was developed to handle graphical operations in windows which confuses me that is it possible to use bitblt in linux.
If you want to perform the same operation on Linux, that BITBLT performs on Windows (which btw, stands for Bit Boundary Block Transfer), you can use a the blit function provided by a game programming library called Allegro.
Related
When I last did this you would use DirectDraw to blit to a hardware surface, or even directly map it and draw directly.
What is the recommended method to do this today? Use Direct3D 10/11 and do the same?
Edit: To clarify my question, I want to do some software rasterization and therefore need a fast way to blit pixel data directly to the display.
I would suggest to use Direct2D which is meant for desktop applications these days. Quote:
Purpose
Direct2D is a hardware-accelerated, immediate-mode, 2-D graphics API
that provides high performance and high-quality rendering for 2-D
geometry, bitmaps, and text. The Direct2D API is designed to
interoperate well with GDI, GDI+, and Direct3D.
Requirements: Vista and higher as well as the respective server versions (if that is needed).
I've been using SDL to render graphics in C. I know there are several options to create graphics at the pixel level on Windows, including SDL and OpenGL. But how do these programs do it? Fine, I can use SDL. But I'd like to know what SDL is doing so I don't feel like an ignorant fool. Am I the only one slightly frustrated by the opaque layer of frosting on modern computers?
A short explanation as to how this is done on other operating systems would also be interesting, but I am most concerned with Windows.
Edit: Since this question seems to be somehow unclear, this is precisely what I want:
I would like to know how pixel level graphics manipulations (drawing on the screen pixel by pixel) works on Windows. What do libraries like SDL do with the operating system to allow this to happen. I can manipulate the screen pixel by pixel using SDL, so what magic happens in SDL to let me do this?
Windows has many graphics APIs. Some are layers built on top of others (e.g., GDI+ on top of GDI), and others are completely independent stacks (like the Direct3D family).
In an API like GDI, there are functions like SetPixel which let you change the value of a single pixel on the screen (or within a region of the screen that you have access to). But using SetPixel to setting lots of pixels is generally slow.
If you were to build a photorealistic renderer, like a ray tracer, then you'd probably build up a bitmap in memory (pixel by pixel), and use an API like BitBlt that sends the entire bitmap to the screen at once. This is much faster.
But it still may not be fast enough for rendering something like video. Moving all that data from system memory to the video card memory takes time. For video, it's common to use a graphics stack that's closer to the low-level graphics drivers and hardware. If the graphics card can do the video decompression directly, then sending the compressed video stream to the card will be much more efficient than sending the decompressed data from system memory to the video card--and that's often the limiting factor.
But conceptually, it's the same thing: you're manipulating a bitmap (or texture or surface or raster or ...), but that bitmap lives in graphics memory, and you're issuing commands to the GPU to set the pixels the way you want, and then to display that bitmap at some portion of the screen (often with some sort of transformation).
Modern graphics processors actually run little programs--called shaders--that can (among other things) do calculations to determine the pixel values. The GPUs are optimized to do these types of calculations and can do many of them in parallel. But ultimately, it boils down to getting the pixel values into some sort of bitmap in video memory.
I sometimes use windows gdi regions for graphics drawing and invalidation/validation. For example the program http://www.maxerist.net/main/soft-for-win/tubicus (oss) was made using only regions (no bitmaps or off-screen buffer). The drawing was made with FillRgn and FrameRgn, invalidation and painting with InvalidateRgn and CombineRgn, every cell (see screenshot) is a simple region created with CreateEllipticRgn, CreatePolygonRgn and CombineRgn.
I have plans to port it to Linux. As I understood, there are many graphics libraries in Linux. Are there ones that support windows-like regions?
Thanks
You want to use The X Window System, a.k.a. X11, as your graphic platform. Its client library is called Xlib. The platform supports polygonal regions.
There are many libraries written on top of Xlib (Gtk, Qt, wxWindows and more) but you always can use the low-level Xlib API directly with any of them. Qt even supports elliptic regions. I don't know the details but I guess it's implemented on top of X11 polygonal regions.
Qt has a lot of options for painting, and using QPainter with QPainterPath objects might suit you well. (There are samples in the Qt distribution). You can combine (add/intersect/substact) paths.
The QGraphicsView framework is a good alternative too.
I am a absolutely new GUI programmer with very little experience (except some small apps in Java). I am considering writing a small app that needs simple 2D graphs. I don't know if I should use Xlib or cairo to do the plots.
Is Xlib's graphic components fast compared to, say, cairo? If cairo is written using Xlib, then the answer would obviously be yes, but I don't know if it is.
Xlib doesn't do any graphics itself. If you are talking about server graphics primitives, they are usually pretty fast these days, but they are also fairly limited (lines, rectangles, polygons, elipses, trapezoids; solid color fills) and tend not to get any special acceleration by the graphics drivers.
Honestly, you ought not program against Xlib or xcb directly. Instead, use a toolkit like Qt, GTK+ or FLTK (or wxWindows, or, or....). They provide a framework for building applications, as well as abstracting away the X details into an easy to use API.
Generally all of the the libraries which leverage Xlib to do their drawing do so in an optimized manner. You would have trouble matching the performance of say, scrolling on your own. You also have no widgets and a library which makes the simplest tasks thousand-line behemoths.
I want to make a skinning engine capable of drawing custom-shaped windows with alpha blending. That is, it'll use layered windows (UpdateLayeredWindow). A typical window will contain among its background a couple dozens of other bitmaps ranging from 10×10 to, say, 300×150 pixels. In the worst case most of these elements will have smooth animation up to 30 fps. Everything will be alpha-blended and I am going to use Direct2D for this (yes, I know older Windows versions doesn't support it). In general, Winamp's modern skin engine is the closest example.
Given all this and taking in account modern PCs performance, can I just redraw the whole window every single frame or do I have to constrain to some sort of clip rectangle?
D2D required you to render with WM_Paint messages
Honneslty, use The IAnimation interface, and just let D2D and windows worry about how often to redraw , though i will let you know , winamp is done with adobe air, and layerd windows with d2d causes issues. (Kinda think you have to use a DXGI render target, but with the window being layerd it needs a DC to be returned to an end paint call so it can update it's alpha channel)
I have some experience with this.
If you need to support Windows XP, using UpdateLayeredWindow is the only choice available for solving this problem. The documentation for this call says it copies the whole bitmap to the screen each time it is called and this bottleneck showed up in my benchmarking as the real limiting factor. If your window is 300x300 you pay that price on every update, even if you are careful to modify only a couple of pixels. It would be very easy to over-optimize the rendering side for no real benefit so implement something simple, measure, and then decide if you need to optimize.
If you can drop support for Windows XP then you can avoid UpdateLayeredWindow completely and use DwmExtendFrameIntoClientArea to create the same effect as a layered window. You'll write less code, avoid the UpdateLayeredWindow bottleneck, and D2D will be easier to work with.