[RESOLVED] Most painless way to get hardware accelerated graphics.

[Niya]

I've been fiddling around with a pet project of mine recently in my spare time(You can see it here). Its a re-write of a screen saver type thing I made years ago in VB6.

I've recently added glow effects for the projectiles and since then, performance has been suffering when there are many entities on the screen and the Form is maximized. Its seems GDI+ has become insufficient. I've optimized the app as much as I could so now the only choice that remains is to use hardware accelerated graphics.

I've been researching a few managed options like SlimDx and SharpDx but there is a problem with these options, dependencies. This project is mainly a hobby, I thing I do for fun and as such I intent to keep on releasing updates to the Codebank. As a general rule, I don't like to release source code that requires people to go elsewhere to download dependencies. When downloading source code myself, I hated having to do that and I won't subject people to that when I release my own application source code.

My question: Are there any assemblies that come with the .Net Framework that provide hardware accelerated graphics operations ?

[dday9]

While I haven't dabbled with it, from what I understand WPF has better graphics capabilities than what a normal windows form application can handle. Here is sort of the hierarchy that I follow when it comes to graphics: windows < WPF < XNA/DirectX. By the way you can still target DirectX 9 with visual basic.net. The trick is targeting the correct framework which I believe is either 3 or 3.5.

[Niya]

Using .Net 3.0 is out of the question so DX9 is also out. Frankly, I can't live without LINQ. I've been looking over the code and I think I may be able to optimize the glow effects by pre-creating the blended images rather than blending at render time. It would require some effort to implement but I should be able to get acceptable performance. I'll post back here when I'm done.

[Niya]

Ok so I've used a combination of caching and pre-creating blends to get back acceptable performance when applying glow effects so I can hold off on hardware acceleration for now. I'll mark this resolved. Thanks for your response Dday

[Shaggy Hiker]

I'm not sure what the conversation about framework 3.0 is about. I'm using XNA while targeting FW 4.0. I think XNA uses DirectX9, though I haven't looked lately. Some version of XNA targets a later version of DirectX than that.

[Niya]

Doesn't really matter which version of DirectX, I just need a fast blitter with the ability to perform alpha blending. I was thinking of using plain old GDI for blitting since I've read that GDI is fully hardware accelerated on XP and blit functions are accelerated on Windows 7. With XNA, if I were to release the source, it would probably mean anyone who wants to download it would also have to download and install dependencies which is why I'm skeptical of using DX based solutions. SlimDX, XNA and SharpDX all require downloads I believe.

[dday9]

I'm not sure what the conversation about framework 3.0 is about. I'm using XNA while targeting FW 4.0. I think XNA uses DirectX9, though I haven't looked lately. Some version of XNA targets a later version of DirectX than that.

Even though XNA is a DirectX wrapper, XNA was designed for FW 4.0(and higher) where as the last managed DirectX version that you're able to use with VS2010(DirectX 9) was designed for FW 3.5(I just confirmed that it is 3.5 and not 3.0) and will not compile on anything higher.

Now if DirectX 11 becomes compatible with VB.Net(which I doubt) it will probably be for 4.0 and higher.

[Shaggy Hiker]

If GDI is fully hardware accelerated on ANYTHING, I haven't noticed it. XNA wasn't just a couple times faster for me, it was a couple hundred times faster, with only laptop graphics, too.

[Niya]

where as the last managed DirectX version that you're able to use with VS2010(DirectX 9) was designed for FW 3.5(I just confirmed that it is 3.5 and not 3.0) and will not compile on anything higher.

I assume you're talking about Managed DirectX ?

If GDI is fully hardware accelerated on ANYTHING, I haven't noticed it. XNA wasn't just a couple times faster for me, it was a couple hundred times faster, with only laptop graphics, too.

I'm aware of your previous thread about using XNA for speeding up your controls. As such, I'm assuming that you're confusing GDI with GDI+. When you use the Graphics object in C#/VB.Net you're actually using GDI+ which is not hardware accelerated. To draw with GDI one needs to P/Invoke BitBlt and its family(StretchBlt, StretchDIBits, AlphaBlend). As far as I've read, these are hardware accelerated in Windows 7. All the other classic GDI operations(line drawing operations and such) are accelerated on WinXP and back.

Now so far I've only read about it. I've yet to compare the speed of GDI to GDI+ so don't take anything as fact until I've confirmed it for myself. Its not like the the various sources of information clearly state that GDI+ is slower than GDI. They sort of imply it.

[Niya]

I've confirmed. GDI is indeed much faster than GDI+. My observations have determined that GDI can be up to 7 times faster than GDI+ when blitting. See for yourself using the attached solution. Just run the solution after loading it into VS. It would measure GDI and show a message box and then it will do the same with GDI+ afterwards.

[Shaggy Hiker]

Yeah, I had never looked at GDI, so I always assumed that when somebody wrote GDI they were just being lazy and leaving out the +. I have heard of all the methods you are talking about, I just didn't realize they were called GDI.

[SJWhiteley]

I really don't think GDI is hardware accelerated (I'd like to see if it's true, or not - if so, I'd go back to GDI for some operations).

It's faster than GDI+ because you are closer to graphical manipulation. 7x speed increase isn't that big of an increase, and I don't think is fast enough to conclude it's hardware accelerated. It's still a marked improvement, though.

If you don't dispose of objects correctly under GDI, you WILL crash your computer at some point. Win7 is better protected than XP, however. It's unfortunate that BitBlt ROP operations didn't get transferred to .NET.

EDIT: Just ran the test project. GDI+ is only a fraction slower than GDI, on my system; and 2.5 times slower on another computer. However, the actual 'results' didn't appear to be the same.

[passel]

Generally, GDI+ is quite a bit faster on Windows7 and 8, than it was on Windows XP, so XP machines should show the biggest difference.
Of course, your example is stretching the image, which slows things down a bit.
On a Windows 7 laptop, generic Intel Graphics (hp EliteBook 8470p), the solution as given gave approximately the following values.
GDI: 3.65
GDI+:3.77

If I changed it to use the bitmap size, so wasn't scaling then GDI+ was a little faster on this machine (alphablend probably doesn't support a non-scaled version, so has additional overhead compared to bitblt):
GDI: 3.22
GDI+: 3.07

If I was trying to draw images quickly, I would use a texturebrush, rather than DrawImage, so trying the same scaled and non-scaled test using texturebrush.
GDI+ TextureBrush w/scale: 1.53
GDI+ TextureBrush : 0.905

The modified code with various things commented out that can be swapped with the other lines to try the various versions. If you use the 100,100 rectangle, then uncomment the tb.scale... commands to scale the texturebrush appropriately, otherwise it tiles.
(and if you weren't drawing at 0,0, you would need to do a translateTransform to see what you'd expect using a texturebrush).

    Dim bmp As Bitmap = My.Resources.TestImage2
    Dim tb As New TextureBrush(bmp)

    Dim iteration As Integer = 10000
    Dim sw As New Stopwatch

    Dim rct As New Rectangle(0, 0, bmp.Width, bmp.Height)
    ' Dim rct As New Rectangle(0, 0, 100, 100)

    sw.Start()
    For i = 1 To iteration
      '  ManagedGDI.AlphaBlend(bmp, e.Graphics, New Rectangle(0, 0, 100, 100), 255)
      ManagedGDI.AlphaBlend(bmp, e.Graphics, rct, 255)
    Next
    sw.Stop()

    MessageBox.Show("GDI: " + sw.Elapsed.TotalSeconds.ToString)
    sw.Reset()

    sw.Start()
    ' tb.ScaleTransform(100 / bmp.Width, 100.0 / bmp.Height)
    For i = 1 To iteration
      ' e.Graphics.DrawImage(bmp, New Rectangle(0, 0, 100, 100))
      '  e.Graphics.DrawImage(bmp, rct)
      e.Graphics.FillRectangle(tb, rct)
    Next
    ' tb.ResetTransform()

    sw.Stop()

    MessageBox.Show("GDI+: " + sw.Elapsed.TotalSeconds.ToString)

[Niya]

I just implemented GDI rendering in the DemonArena project and to my disappointment, it really didn't bring any improvement. In fact, it degraded slightly. I did a little more testing and it seems when double buffering is set, GDI+ came very close to GDI's performance. If you set the Form to double buffer in the original test code I posted, surprisingly GDI+ will exceed GDI's performance by up to a factor of 2(On my PC at least). Combine that with passel's observations about scaling, I can only conclude that its best I stick with GDI+ since GDI is much more difficult to work with and I will get no benefit.

Thank you guys for all your contributions but I've done all I could with GDI/GDI+. At this point, the only way I can achieve remarkable performance is through DirectX. There's no escaping that now.

[Niya]

What the.....did Edgemeal's post just go missing ??? I was just repping it and it told me the post was invalid.

[dday9]

What the.....did Edgemeal's post just go missing ??? I was just repping it and it told me the post was invalid.

I didn't even know that Edgemeal posted.

[Niya]

I didn't even know that Edgemeal posted.

Yea, he posted some performance results from running my test code on different PCs.

[Shaggy Hiker]

Thank you guys for all your contributions but I've done all I could with GDI/GDI+. At this point, the only way I can achieve remarkable performance is through DirectX. There's no escaping that now.

You have no idea of the power of the dark side...

[passel]

I thought the times may have been shorter the first time I ran the code, but didn't write anything down, so after a number of runs with the same result (3+ seconds), I figured I was mistaken.

So, I re-extracted the original code form the zip again, and ran it, and it did run faster, although on this machine, the GDI and GDI+ times are still fairly close.
GDI: 1.636
GDI+: 1.876

Turns out, adding the textureBrush all by itself, even if not used, causes a slowdown in access to the original bmp.
So, adding this one line by itself.

Dim tb As New TextureBrush(bmp)

Causes both DrawImage and AlphaBlend to slow down on this machine to the 3+ times.
So, the "fix" is to dispose of the bitmap used to create the texturebrush, and generate a new bitmap for use by drawImage and AlphaBlend.

Dim bmp As New Bitmap(My.Resources.TestImage2)
Dim tb As New TextureBrush(bmp)
bmp.Dispose()
bmp = New Bitmap(My.Resources.TestImage2) 'My.Resources.TestImage2

So, added the above and a third case to Niya's code and the results on this machine with the below code (for one run) was:
GDI : 1.592342
GDI+ : 1.9070751
GDI+ txtBrush : 1.5714507.

So, not a lot of difference on this particular machine between the three methods (19% worse case, with texturebrush being slightly faster).
Of course one thing mentioned earlier, is that the resulting image is not the same. Both GDI methods, by default are going to smooth the image so pretty much look identical, doing anti-aliasing type pixel adjustments where different colors meet. If you capture the images and blow them up, the AlphaBlend result is much more blocky by comparison.

    Private Sub Form1_Paint(ByVal sender As Object, ByVal e As System.Windows.Forms.PaintEventArgs) Handles Me.Paint

        'Rumored to be the fastest GDI+ however, I've observed
        'no change in performance
        '*****************************************
        'e.Graphics.CompositingMode = Drawing2D.CompositingMode.SourceOver
        'e.Graphics.CompositingQuality = Drawing2D.CompositingQuality.HighSpeed
        ' e.Graphics.SmoothingMode = Drawing2D.SmoothingMode.None
        'e.Graphics.PixelOffsetMode = Drawing2D.PixelOffsetMode.Half
        'e.Graphics.InterpolationMode = Drawing2D.InterpolationMode.NearestNeighbor
        '*****************************************

        Dim bmp As Bitmap = My.Resources.TestImage2
        Dim tb As New TextureBrush(bmp)
        bmp.Dispose()
        bmp = My.Resources.TestImage2

        Dim iteration As Integer = 10000
        Dim sw As New Stopwatch

        sw.Start()
        For i = 1 To iteration
            ManagedGDI.AlphaBlend(bmp, e.Graphics, New Rectangle(0, 0, 100, 100), 255)
        Next
        sw.Stop()

        MessageBox.Show("GDI: " + sw.Elapsed.TotalSeconds.ToString)
        sw.Reset()

        sw.Start()
        For i = 1 To iteration
            e.Graphics.DrawImage(bmp, New Rectangle(0, 0, 100, 100))
        Next
        sw.Stop()

        MessageBox.Show("GDI+: " + sw.Elapsed.TotalSeconds.ToString)
        sw.Reset()

        sw.Start()
        tb.ScaleTransform(100 / bmp.Width, 100.0 / bmp.Height)
        For i = 1 To iteration
            e.Graphics.FillRectangle(tb, New Rectangle(0, 0, 100, 100))
        Next
        tb.ResetTransform()

        sw.Stop()

        MessageBox.Show("GDI+ txtBrsh: " + sw.Elapsed.TotalSeconds.ToString)

    End Sub

[passel]

What the.....did Edgemeal's post just go missing ??? I was just repping it and it told me the post was invalid.

You're talking post #14, it is still there in my browser.., whoa, wait a-minute there are two Posts #14, one by Edgemeal and one by Niya.
I guess you only have scope to see your 14, and you're hiding the "outer" scope.

Maybe I should copy Edgemeal's post here, in case it goes away for everyone.

Re: [RESOLVED] Most painless way to get hardware accelerated graphics.

Originally Posted by passel View Post
Generally, GDI+ is quite a bit faster on Windows7 and 8, than it was on Windows XP, so XP machines should show the biggest difference.
Of course, your example is stretching the image, which slows things down a bit.
On a Windows 7 laptop, generic Intel Graphics (hp EliteBook 8470p), the solution as given gave approximately the following values.
GDI: 3.65
GDI+:3.77

Hmmm thats like no acceleration at all.

FWIW, here's what I got running Niya's code as is,

Intel i5-3570 w/Intel HD 4000 / 8GB DDR3-1600 / Win7 Ultimate.
GDI: 0.98
GDI+ 2.74

Intel i7-3770 w/AMD Radeon 6670 1GB-DDR3 / 8GB DDR3-1600 / Win7 Home Prem.
GDI: 0.92
GDI+ 3.15

EDIT: tried your code on i7-3770 w/Radeon,
GDI: 1.89
GDI+: 2.05

[Edgemeal]

Maybe I should copy Edgemeal's post here, in case it goes away for everyone.

Sorry, removed it, just seemed irrelevant after Niya mentioned double buffer and the results changed.

Niya's w/double buffered enabled, on i7-3770 sys...
GDI: 1.174 , GDI+: 0.940

[SJWhiteley]

...

Thank you guys for all your contributions but I've done all I could with GDI/GDI+. At this point, the only way I can achieve remarkable performance is through DirectX. There's no escaping that now.

This is the reality. Any serious game/animation needs a proper hardware rendering engine.

To be fair, you can get excellent results with GDI (I used it heavily in VB6) if you are intelligent with sprite rendering, and take care with the handles and device contexts, but WPF/XNA/DirectX are, seemingly, infinitely faster.

[boops boops]

I have some criticisms of the testing methods used so far. In my view the testing method is producing misleading results.

With my own code, the results are rather different but the general conclusion -- use GDI+ with double buffering -- is the same. Still, I suspect there may be something wrong with this result because previous tests have shown double buffering to be significantly slower.

When displaying a small image without per-pixel alpha blending (Niya's FRO16A1.png), GDI+ is faster than GDI without DoubleBuffering, but they slow to about the same speed with DoubleBuffering (presumably that's the DB overhead). When displaying a larger image with partial transparency (BabyGeorge.png) in GDI+, it is much slower (about 5x) compared to the present GDI code which is rendering the alpha as opaque. But double buffering more than makes up the difference! GDI+ is now faster than GDI. I wonder why?

My comments about the present testing method are as follows:

1. There is no point in timing looped instructions inside the Paint event. You can repeat Graphics.PaintImage 100,000 times but the image will be painted only once. Testing inside the Paint sub doesn't even include the actual rendering. It is more correct to measure the time to Refresh the control, because that covers the whole painting operation. This seems to apply to the GDI method used as well as to GDI+.

2. A large number of iterations doesn't add useful information. Sometimes you must ignore the first few test results at runtime because of JIT compilation, but otherwise a few iterations are enough to give a good impression of differences at the millisecond scale.

3. Niya's test image doesn't have any partially transparent pixels, so it doesn't test alpha blending. Besides, the GDI code renders its totally transparent pixels as white, not as transparent. That makes it hard to compare alpha blending between GDI+ and GDI.

4. A minor point. The GDI code renders the image as pixel blocks, so it's a fairer comparison to do the GDI+ rendering with InterpolationMode.NearestNeighbour.

5. I haven't got around to looking at Passel's TextureBrush approach but it surprises me greatly that it shows a significant difference.

Here's my own form code which measures Refresh time. It uses a checkered background to disclose transparency. To try it, add a new form to Niya's project, copy this code in, and set it as the startup form. Also add the checker tile and the BabyGeorge image from the attached zip file to the project resources. Click the form to select a different image (at the moment a primitive alternation between 2 images).

	Private WithEvents Button1 As New Button With {.Text = "test", .Width = 50, .Location = New Point(10, 0)}
	Private WithEvents CheckBox1 As New CheckBox With {.Text = "Use GDI+", .Location = New Point(Button1.right + 8, 0)}
	Private WithEvents CheckBox2 As New CheckBox With {.Text = "DoubleBuffer", .Location = New Point(CheckBox1.Right, 0)}
	Private WithEvents NumericUpdown1 As New NumericUpDown With {.Value = 1, .Minimum = 1, .Maximum = 1000, _
	 .Location = New Point(CheckBox2.right, 2), .Width = 50, .TextAlign = HorizontalAlignment.Center}

	Private Label1 As New Label With {.Text = "iterations", .Location = New Point(NumericUpdown1.right + 2, 6)}
	Private useGDI_Plus As Boolean = False
	Private iterations As Integer = 1
	Private sw As New Stopwatch
	Private bmp As Bitmap

	Private Sub Form2_Click(sender As Object, e As System.EventArgs) Handles Me.Click
		Static other As Boolean
		If other Then bmp = My.Resources.BabyGeorge Else bmp = My.Resources.TestImage2
		other = Not other
	End Sub

	Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
		Me.Controls.AddRange({Button1, CheckBox1, CheckBox2, NumericUpdown1, Label1})
		Me.BackgroundImage = My.Resources.checker16x16
		Me.BackgroundImageLayout = ImageLayout.Tile
		bmp = My.Resources.TestImage2
	End Sub

	Private Sub Button1_Click(sender As Object, e As System.EventArgs) Handles Button1.Click

		iterations = CInt(NumericUpdown1.Value)
		useGDI_Plus = CheckBox1.Checked
		Me.DoubleBuffered = CheckBox2.Checked

		sw = Stopwatch.StartNew
		For i As Integer = 1 To iterations
			Me.Refresh()
		Next
		sw.Stop()

		Console.Write("Image size = {0}, render size = {1}. ", bmp.Size.ToString, Me.ClientSize.ToString)
		Console.WriteLine("GDI plus = {0}, iterations = {1}, double buffered = {2}: {3} ms.", _
		useGDI_Plus, iterations, DoubleBuffered, sw.Elapsed.TotalMilliseconds)

	End Sub

	Private Sub Form1_Paint(ByVal sender As Object, ByVal e As System.Windows.Forms.PaintEventArgs) Handles Me.Paint
		'If clearBitmap Then Exit Sub
		e.Graphics.InterpolationMode = Drawing2D.InterpolationMode.NearestNeighbor
		If useGDI_Plus Then
			e.Graphics.DrawImage(bmp, Me.ClientRectangle)
		Else
			ManagedGDI.AlphaBlend(bmp, e.Graphics, Me.ClientRectangle, 255)
		End If
	End Sub

Typical output using Niya's image:

Image size = {Width=64, Height=128}, render size = {Width=705, Height=540}. GDI plus = False, iterations = 1, double buffered = False: 23,9752 ms.
Image size = {Width=64, Height=128}, render size = {Width=705, Height=540}. GDI plus = False, iterations = 1, double buffered = True: 27,0093 ms.
Image size = {Width=64, Height=128}, render size = {Width=705, Height=540}. GDI plus = True, iterations = 1, double buffered = False: 10,4691 ms.
Image size = {Width=64, Height=128}, render size = {Width=705, Height=540}. GDI plus = True, iterations = 1, double buffered = True: 27,214 ms.

With my larger image and alpha-blending in GDI+ (but not in GDI) the results were:

Image size = {Width=494, Height=522}, render size = {Width=705, Height=540}. GDI plus = False, iterations = 1, double buffered = False: 31,7403 ms.
Image size = {Width=494, Height=522}, render size = {Width=705, Height=540}. GDI plus = False, iterations = 1, double buffered = True: 30,4077 ms.
Image size = {Width=494, Height=522}, render size = {Width=705, Height=540}. GDI plus = True, iterations = 1, double buffered = False: 117,0271 ms.
Image size = {Width=494, Height=522}, render size = {Width=705, Height=540}. GDI plus = True, iterations = 1, double buffered = True: 22,9533 ms.

[Niya]

Update on the situation:

I just implemented an DirectX renderer using XNA and the performance is truly astonishing. I stress tested it with 5000 entities and all of them still move quite smoothly with an acceptable loss of performance, like a relatively tiny loss. Under GDI/GDI+ the performance is very very bad with 5000 entities. They almost aren't moving. DirectX is seriously fast and I mean seriously!

[Shaggy Hiker]

Yeah, that was pretty much my reaction, too.

[hynsey]

Update on the situation:

I just implemented an DirectX renderer using XNA and the performance is truly astonishing. I stress tested it with 5000 entities and all of them still move quite smoothly with an acceptable loss of performance, like a relatively tiny loss. Under GDI/GDI+ the performance is very very bad with 5000 entities. They almost aren't moving. DirectX is seriously fast and I mean seriously!

Hi Niya,
Can you provide any pointers/sample code on how you implemented DirectX? I'm looking to paint images on a form (PictureBox, or Panel or whatever), and current techniques are using too much CPU. I'm looking to paint between 8 and 15 images per second. Any help would be hugely appreciated.
Cheers,
hynsey

[Niya]

Take a look at this thread. It's where I first learned to use XNA to draw to a control.

If you're still having trouble figuring it out then make a thread as ask about it so others can help you if I'm not around.

[hynsey]

Take a look at this thread. It's where I first learned to use XNA to draw to a control.

If you're still having trouble figuring it out then make a thread as ask about it so others can help you if I'm not around.

cheers Niya, I'll check that out. Appreciate it!

[jayinthe813]

Well.... Theres always Visual C++

[Niya]

C++ wouldn't help you paint images any faster.

[jayinthe813]

C++ wouldn't help you paint images any faster.

Not in the way you are painting, but there are more graphics libraries however. Also math, there are a lot of decent math libraries as well.

[Niya]

You misunderstand, painting is an OS implementation. It is done through the Windows message WM_PAINT which then draws a DC. You cannot change this behavior through use of a different language. DirectX, however can circumvent this behavior and DirectX, while primarily accessed through C++ libraries, can also be accessed through bindings in other languages.

[jayinthe813]

Are you saying that all graphics derive from os paint method? And that most engines to create graphics are painting?

[Niya]

If you're using GDI or GDI+ then you are very likely using it with WM_PAINT. The Paint event of the Control class in .Net is raised by a WM_PAINT message. When you override OnPaint to draw in .Net, you normally use GDI+ to draw.

DirectX on the other hand, which games use, gives you more direct access to the video hardware. You don't have to rely on Paint events.

[jayinthe813]

If you're using GDI or GDI+ then you are very likely using it with WM_PAINT. The Paint event of the Control class in .Net is raised by a WM_PAINT message. When you override OnPaint to draw in .Net, you normally use GDI+ to draw.

DirectX on the other hand, which games use, gives you more direct access to the video hardware. You don't have to rely on Paint events.

Oh Ok, I was alluding to changing to C++ so you can use something other than GDI, I see so many people complain how slow GDI often is. C++ in my experience isn't very fun. See your signature for more relevant info .

But Cinder looks cool:

https://www.youtube.com/watch?v=hwHYJM2GV1U
http://libcinder.org/

[Niya]

C++ has the advantage of having all the latest toys where graphics is concerned. They have all the latest DirectX and OpenGL stuff. VB6 and VB.Net lag far behind.

[dday9]

The latest version of DirectX that you're able to use is 9 and they've already announced a version 12, so that is about 9 years behind(10 came out in '06). Microsoft tried to fix this by coming out with XNA, but the issue with XNA was that only some versions supported VB.Net plus the inadequate documentation on the various classes and namespaces made it a daunting task to try and pick up. Slowly but surely XNA suffered a slow and quiet death although it will still be supported, I'm sure it's support will be to the same extent as VB6 is still supported. VB.Net does have an OpenGL library, but I personally have never really looked into it. So I don't know which version it runs.

At this point, I don't see any viable solution for advanced graphics in VB.Net. We're kind of in limbo to see what Microsoft plans to do, if anything. At this point I believe if you want advanced graphics libraries going forward, then the best solution would be to use C++.

In an unrelated note - I like turtles.