Fast Pixel Drawing Library

Fast pixel drawing library

Are your pixels sparse or dense (e.g. a bitmap)? If you are creating dense bitmaps out of pixels, then another option is to convert the bitmap into an OpenGL texture and use OpenGL APIs to render at some framerate.

The basic problem is that graphics hardware will be very different on different hardware platforms. Either you pick an abstraction layer, which slows things down, or code more closely to the type of graphics hardware present, which isn't portable.

Fast, Pixel Precision 2D Drawing API for Graphics App?

I just this week put together some slides and demo code for doing 2d graphics using OpenGL from python using the library pyglet. Here's a representative post: Pyglet week 2, better vertex throughput (or 3D stuff using the same basic ideas)

It is very fast (relatively speaking, for python) I have managed to get around 1,000 independently positioned and oriented objects moving around the screen, each with about 50 vertices.

It is very portable, all the code I have written in this environment works on windows and Linux and mac (and even obscure environments like Pypy) without me ever having to think about it.

Some of these posts are very old, with broken links between them. You should be able to find all the relevant posts using the 'graphics' tag.

drawing a pixelarray fast and efficient on linux

Drawing graphics on Linux you either have to use X11, or OpenGL. (And in the near future Wayland may be another option). In Linux there is no "native" way of doing graphics, because the Linux kernel doesn't care about graphics APIs. It provides a interfaces (DRM) using which graphics systems are then implemented in user space. If you just want to splat pixels on the screen, without caring about windows then you could also mmap /dev/fbdev – but you normally don't want that, because nobody wants his screen being clobbered by some program he can't move or hide.

Drawing single points is inefficient, no matter which API being uses, due to the protocol overhead.

So X11 it is. So the best bet is to use the MIT-SHM extension which you use to alter pixels in a buffer, which is then blitted in whole by the X11 server. Of course doing this using the pure X11 Xlib functions is annoyingly cumbersome. So this is what SDL effectively nicely wraps up for you.

The other option is OpenGL. OpenGL is not a library! It's a system level API, that gives you almost direct access to the GPU. And it integrates nicely with X11. Yes, the API is provided through a library that's being loaded, but technically that library is just a "wrapper" or "interface" to the actual driver. Drawing single points with OpenGL makes no sense. But you can "batch up" several points into a list (using a vertex array) and then process that list. So the idea is to collect all the incoming points between two display refresh intervals and draw them in one single batch.

platform independent solutions are preferred.

Why are you asking about native APIs then? By definition there can be no plattform independent native API. Either you're native, or you're plattform independent.

And in your particular scenario I think SDL would be the best solution, because it offers just the right kind of abstraction and program side interface for a raytracer. Just FYI: Virtual Machines like QEmu use SDL.

Or you use OpenGL which is a real plattform neutral API widely supported.

Fast pixel drawing in WPF

Interesting, but with raytracing, writing the pixels to the screen will (should) not be the slow part. You can use WriteableBitmap for the purpose, though. It's certainly quick enough for what you want.

http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.writeablebitmap.aspx

(For info, I use it in this emu/IDE - http://0x10c-devkit.com/ - and it can refresh a low res display with great performance. There's the source to that on the github repository, the LEM1802 plugin.)

Ah, this bit: https://github.com/kierenj/0x10c-DevKit/blob/master/PluginAPI/NyaElektriska.LEM1802/GPU.cs - see UpdateDisplay.

Haskell pixel drawing library linux

It looks to me like you aren't actually drawing anything there. Are you sure setColors does what you think it does? If memory serves me, it's for setting the color palette for an 8-bit surface, whereas you're explicitly setting a 32-bit video mode.

As an aside, if you've done graphics programming before I'm sure you know the difference, but for the benefit of others reading this: 8-bit video modes store pixel colors as an 8-bit index into a table of 256 colors chosen from a much larger set of potential colors; in higher color depths, the palette table is dispensed with and each pixel color is stored directly as a packed RGB triple, typically of 8 bits each (32-bit pixels either have an 8-bit alpha channel as well, or just 8 bits of padding for better memory alignment, I can't recall).

Either way, if I'm guessing correctly what you were attempting to do, try adding this to your program:

import Ix

-- Given coordinates, create a 1x1 rectangle containing that pixel
getPix x y = SDL.Rect (fromIntegral x) (fromIntegral y) 1 1

-- Draw a pixel on a surface with color determined by position
drawPixel surf (x, y) = do
    let pixRect = Just (getPix x y)
    pixColor <- createColor surf x y 255
    SDL.fillRect surf pixRect pixColor

-- Apply drawPixel to each coordinate on the screen
drawGrad screen = mapM_ (drawPixel screen) $ range ((0,0),(255,255))

Warning: That's almost certainly horrible and inefficient code, and it has been tested only in a Win32 environment. I am not a qualified Haskell programmer and my advice should not be taken as indicative of correct use of the language. For external use only. Do not taunt the Happy Fun IO Monad.

Either way, I think your problem lies with use of SDL, not Haskell. Graphics.UI.SDL is pretty raw, little more than wrapping the C API in appropriate Haskell types. If you've not used SDL before, or used it only with slightly more elaborate bindings (e.g., PyGame), you may want to consider looking for SDL examples in C as reference material.

Is there any low level way to draw pixels to the screen?

The last system I know which allowed direct video access to user program was the good old MS/DOS. I assume than its derivatives like FreeDOS still allow that. The problem is that in modern OS, a process can only access its own memory and must ask the OS for any other memory access. And as the video is shared by many processes (including system processes) only system API can directly control it.

You normally can find API that allows you to draw bitmaps on a copy of the video memory and then flush it, or that offer higher level accesses. Depending on the system you can even find APIs that map the actual video memory into your address space. But you must first ask kindly to the kernel...

C# fast pixel rendering

If you're using Bitmaps, then you should use LockBits and UnlockBits to access the data directly in memory. In C#, you can get some extra performance by using unsafe code blocks and pointers.

See this link for more information: http://web.archive.org/web/20150227183132/http://bobpowell.net/lockingbits.aspx

---

Related Topics