Recent

Author Topic: Fast drawing  (Read 15280 times)

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Fast drawing
« Reply #15 on: May 08, 2015, 11:34:05 pm »
Also if you check bgragtkbitmap.pas code you can find drawing method on Gtk where to each pixel SwapRedBlue is applied. It is done even twice to change color back and forth. You can guess how much CPU time is needed to process FullHD or 4K image. It would be probably much better to translate image only in one way and have allocated auxiliary memory area. So it would need more memory but less CPU time.
This is also interesting that in case of Gtk backend you need more processing then with windows backend just because of pixel format. If library name would be RGBABitmap then it would have faster drawing on Gtk. So choosing color format is important to achieve fastest drawing speed.
I agree. I have thought about making a version of BGRABitmap where red/blue are fundamentally swaped so that it is not necessary to do it when calling Gtk functions.

About the speed of swapping twice red/blue, I am not sure it would be better to allocate, because the cache accelerates when less memory is used.
Conscience is the debugger of the mind

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: Fast drawing
« Reply #16 on: May 09, 2015, 05:25:29 am »
is this a game?
try bare game http://forum.lazarus.freepascal.org/index.php/topic,27305.msg168612.html#msg168612

or if you dont care using pascal use Unity

if its an ui i dont know

aradeonas

  • Hero Member
  • *****
  • Posts: 824
Re: Fast drawing
« Reply #17 on: May 09, 2015, 07:01:40 am »
No its not a game.And yes I want to make it in pascal.It is like an splash.

Carver413

  • Full Member
  • ***
  • Posts: 119
Re: Fast drawing
« Reply #18 on: May 11, 2015, 05:18:40 am »
About the speed when refreshing the content of the screen, if we still use GDI/Gtk, the best improvement is to define the area to be invalidated. So instead of doing Form1.Invalidate, you would do InvalidateRect(Form1.Hanlde, @area, False).

Note that if there are multiple rectangular areas, you can call InvalidateRect for all the rectangles.

Otherwise, yeah, it would be necessary to use another basic graphic layer. Maybe it would be possible to do a version of BGRABitmap for OpenGL/DirectX. I don't know.
have you ever considered an OpenCl solution, there seems to be some support for working with images.
http://www.thebigblob.com/gaussian-blur-using-opencl-and-the-built-in-images-textures/
there is one example in fpc that seems to work. if one could build a opencl driven bitmap and combine it with opengl that would really have potential

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Fast drawing
« Reply #19 on: May 11, 2015, 10:57:03 am »
I don't see how this would be done. Could you explain how this would work?
Conscience is the debugger of the mind

Carver413

  • Full Member
  • ***
  • Posts: 119
Re: Fast drawing
« Reply #20 on: May 12, 2015, 01:30:48 am »
I haven't played around with opencl at this point so I have no answer just yet but I will play around with it and see what I can figure out.

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Fast drawing
« Reply #21 on: May 12, 2015, 12:19:48 pm »
Ok.

I had a look at OpenGL, and I suppose it would be possible to plug BGRABitmap into OpenGL to some extent. However, it seems it would require RGBA channel order. This, and also the fact that Gtk require RGBA order, is a incentive to do an RGBA version of BGRABitmap.
Conscience is the debugger of the mind

aradeonas

  • Hero Member
  • *****
  • Posts: 824
Re: Fast drawing
« Reply #22 on: May 12, 2015, 12:25:05 pm »
Good.
If you make a plan for it let us know.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Fast drawing
« Reply #23 on: May 12, 2015, 01:53:08 pm »
Maybe it would be possible to do a version of BGRABitmap for OpenGL/DirectX. I don't know.

If you have to update the 32-bit fullhd image each time, that is painful too, specially on integrated graphics. Texture upload is supposed to happen only occasionally.   

Recently Intel enabled something in the Intel Haswell driver that accelerates uploading a bit, but pre haswell hardware is still too common.

(for magnitude 28Mpixel mono image takes about 3.3ms upload on a haswell 3.2GHZ, but 20ms+ on an 2.8 GHz Ivy Bridge). 

IOW opengl is also that the creation of the final image is done in hardware, not just the final rendering.

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Fast drawing
« Reply #24 on: May 12, 2015, 03:30:31 pm »
I see. So that's interesting only if the same image is used multiple times.
Conscience is the debugger of the mind

Carver413

  • Full Member
  • ***
  • Posts: 119
Re: Fast drawing
« Reply #25 on: May 13, 2015, 02:08:43 am »
thats why I'm looking into opencl from what I've read so for it is possible to link with opengl and create a texture space that would be shared by both. that way you could use opencl to draw and opengl to display. of course it not an easy setup but if it could work it could open many possibility’s for graphic coders like our selfs. of course it is possible to create images with opengl alone but I'm not sure that is the best way for pixel level design. I have a framework that I have been working on for some time that uses opengl to display but all texture creation is done with the cpu alone so many features would not fair well in real time display. not a big deal for me since these textures can be pre rendered  but still it would be nice to have a faster solution. I'll keep you posted if I am able to get something working.

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Fast drawing
« Reply #26 on: May 23, 2015, 12:57:35 am »
Hello people!

Latest version of BGRABitmap is slightly faster on Linux because RGBA order is used.

Also now OpenGL is available, using GL and GLU functions that are defined in FreePascal.
Conscience is the debugger of the mind

Chronos

  • Full Member
  • ***
  • Posts: 240
    • PascalClassLibrary
Re: Fast drawing
« Reply #27 on: May 31, 2015, 10:55:55 am »
Latest version of BGRABitmap is slightly faster on Linux because RGBA order is used.
Nice, I would expect that as library is called BGRA that you will never use different pixel format like RGBA.
Do you have some measurements how faster it is? Lets say for Full HD resolution.
Are there some consequences of different pixel format? Image data are corectly loaded and saved to files or converted to other LCL structures without any problem?

Also now OpenGL is available, using GL and GLU functions that are defined in FreePascal.
It seems that this backend is not set automatically for any platform. It will be able to select this backend in LazPaint to test speed? Can OpenGL really help to LazPaint as bitmap editor? It can be used just as final drawing part or can speed up some image operations in future?

circular

  • Hero Member
  • *****
  • Posts: 4196
    • Personal webpage
Re: Fast drawing
« Reply #28 on: May 31, 2015, 01:53:06 pm »
Quote
I would expect that as library is called BGRA that you will never use different pixel format like RGBA.
On one side, we want speed and on the other side, we want same pixel format. Those wishes are contradictory.

It is possible to use BGRA order anyway by changing compiler directives (in package options, section "other"). Simply add the following:
dBGRABITMAP_BGRAPIXEL

The only thing that one need to be careful about is when writing/reading directly TBGRAPixel records, or if you access components using PByte. One can call SwapRedBlue before and after saving/loading the data if the value of TBGRAPixel_RGBAOrder is different from what is wanted. Otherwise what can happen is that red and blue colors are swapped. If you use functions provided in BGRABitmap, this is taken into account. Unless I made a mistake of course.

So I would say that for most users, that don't use PByte or blockread/blockwrite image data, nothing changes.

Quote
It seems that this backend is not set automatically for any platform. It will be able to select this backend in LazPaint to test speed? Can OpenGL really help to LazPaint as bitmap editor? It can be used just as final drawing part or can speed up some image operations in future?
No no, it is not used by TBGRABitmap. It is an extension for OpenGL with objects names prefixed by "TBGL". One could imagine that the OpenGL version would provide some acceleration for some things, however that would only be with the packages like BGRABitmapPack4LCL_OpenGL or BGRABitmapPack4NoGui_OpenGL.
Conscience is the debugger of the mind

 

TinyPortal © 2005-2018