Why it is considerably faster to use built-in graphics functions?

General
1

Hey there,

I have started taking more interest in the hardware side of things with computers, simply because I feel like I have really missed some basic stuff that may or may not be useful towards my programming.

I will use scaling functions as an example.

It seems that scaling with a built-in Xojo function (or using functions built into the OS) is far superior (in general) to writing your own function to process the pixels.

I am guessing this is because you directly use the GPU to handle this? Or is it because the chances are that the code will be more mature and optimised than what people have already written in Xojo? Or is it because of the speed of compiled Xojo code (no matter how well written it is)?

Not that I plan to ever do this but is it possible to directly program the GPU to create something like a fast scaling function?

Just curious really. Not sure how important this knowledge would be for graphics programming.

Thanks

2

I don’t know the ins outs for programing but in the image rendering world the difference in speed is incredible, the company I beta test for have a CUDA and Embree hybrid render system
One downside is your end user needs a decent GPU, if you opt for CUDA your limited to NVidia video cards, for rendering the card needs at least 2GB of Vram as everything gets rammed in there.

Worth a mention Embree works with AMD chips and actually out preforms Intel’s if there’s enough cores
if your interested heres some stats
http://www.thearender.com/cms/images/edition13/TheaPrestoGPUCPUBenchmark.pdf
my pc is the cr**y Quadro 600 Core i7-3770K @ 3.5 Ghz 5th from the bottom lol

3

It’s more than likely because the built in functions are written in C/C++ which will run faster than Xojo. If you want to write your own really fast graphics manipulation functions you will need to write a Xojo plugin.

4

[quote=130272:@Oliver Scott-Brown]It seems that scaling with a built-in Xojo function (or using functions built into the OS) is far superior (in general) to writing your own function to process the pixels.

I am guessing this is because you directly use the GPU to handle this? Or is it because the chances are that the code will be more mature and optimised than what people have already written in Xojo? Or is it because of the speed of compiled Xojo code (no matter how well written it is)?

Not that I plan to ever do this but is it possible to directly program the GPU to create something like a fast scaling function?

Just curious really. Not sure how important this knowledge would be for graphics programming.[/quote]
Here what I can tell you (with my limited knowledge of what Xojo does under the hood), on OS X (which is my primary target), Xojo uses the Core Graphics APIs (which you can also declare into), these APIs are at the core of every drawing function used in almost every application, even if you use NSGraphics functions, they resolve down to CoreGraphics.

Core Graphics is heavily optimized and takes advantage of the GPU where it can, there are some things you need to use declares for (such as CGLayers) which can make drawing even quicker (in some circumstances).

I would imagine that on Windows & Linux, Xojo does the same and uses the OS graphics toolbox, which should give you the most optimized functions for tasks.

On OS X, you also have Core Image. Core Image is one of my favorites as it’s highly optimized for pixel manipulations, it will use multi-core processors, GPUs, all without you having to worry or care. It’s so much faster than anything else I’ve come across. Not to say that’s perfect, it has warts and while simple to get started, it also has preferred working paths which no books or online articles task about, once you find these paths, it makes the whole world if difference.

At WWDC this year, Apple explained a change they made in Core Image on iOS (for iOS 8), which gave a 17x performance improvement. You as a developer, don’t need to do anything to take advantage of this!

5

[quote=130343:@Sam Rowlands]Here what I can tell you (with my limited knowledge of what Xojo does under the hood), on OS X (which is my primary target), Xojo uses the Core Graphics APIs (which you can also declare into), these APIs are at the core of every drawing function used in almost every application, even if you use NSGraphics functions, they resolve down to CoreGraphics.

Core Graphics is heavily optimized and takes advantage of the GPU where it can, there are some things you need to use declares for (such as CGLayers) which can make drawing even quicker (in some circumstances).

I would imagine that on Windows & Linux, Xojo does the same and uses the OS graphics toolbox, which should give you the most optimized functions for tasks.

On OS X, you also have Core Image. Core Image is one of my favorites as it’s highly optimized for pixel manipulations, it will use multi-core processors, GPUs, all without you having to worry or care. It’s so much faster than anything else I’ve come across. Not to say that’s perfect, it has warts and while simple to get started, it also has preferred working paths which no books or online articles task about, once you find these paths, it makes the whole world if difference.

At WWDC this year, Apple explained a change they made in Core Image on iOS (for iOS 8), which gave a 17x performance improvement. You as a developer, don’t need to do anything to take advantage of this![/quote]
Cool thanks. Is there a GCLayer equivilent for Windows and Linux? Is there an API that makes no extra work for you to use GCLayers but alternate drawing functions to Windows and Linux compatibility? Thanks

6

I don’t know, last time I checked (4 years ago), there wasn’t anything like this in Windows. However Since then, Windows 7 & 8 have been released.

7

I doubt much has changed. They don’t seem to improve the graphics for GDI Plus and it still feels like the old fashioned GDI plus in Windows XP.

8

From a little look at Wikipedia. It looks like they have not really improved much in terms of features for performing tasks that could not be previously done in XP.

9

I am not (yet) into Windows as a target platform, but don‘t they have all that graphics libraries that are used for games programming? There should certainly be some image manipulation methods available.

10

There is Direct2D, have no idea if Xojo supports this well. I believe Xojo’s framework is limited to GDI plus.

11

Clicked answer button by accident sorry.

OpenGL and DirectX are probably the standard.

12

On a Mac, you can declare into any framework the system finds (as long as it‘s 32 bit). Why should that be different under Windows?

13

I was talking about the Xojo framework in general than using what declares give you access to.

14

https://wiki.mozilla.org/Platform/Features/AzureD2DCanvas

This looks like an interesting project.

15

Oh yes, I see. You would have to convert the image data to another Windows OS format probably.

16

An extract from this site (where they explain the different options in Windows): http://msdn.microsoft.com/en-us/library/windows/desktop/ee417756(v=vs.85).aspx

“Use Direct3D 11 to take advantage of the next generation of video hardware on Windows Vista, Windows 7, and Windows 8. Windows Store apps must use Direct3D 11 or later.”

Julen

17

[quote=130499:@Julen Ibarretxe Uriguen]An extract from this site (where they explain the different options in Windows): http://msdn.microsoft.com/en-us/library/windows/desktop/ee417756(v=vs.85).aspx

“Use Direct3D 11 to take advantage of the next generation of video hardware on Windows Vista, Windows 7, and Windows 8. Windows Store apps must use Direct3D 11 or later.”

Julen[/quote]
Thanks.

18

It would be foolhearty to look for the exact counterpart of Cocoa Core Graphics under Windows. Unfortunately, Windows architecture is quite different, and Microsoft elected not to provide the same kind of services.

Most game developers on Windows have their own proprietary graphic technology software. Microsoft provides only basic ways of accessing the screen and graphic processing units.