Julia set fractal generator optimisation (drawpoint)

About Monkey 2 Forums Monkey 2 Programming Help Julia set fractal generator optimisation (drawpoint)

This topic contains 8 replies, has 5 voices, and was last updated by  taumel 2 years, 10 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #2203


    I made a little Julia set fractal generator.

    My main issue is that drawpoint is actualy very slow for real time plot by plot generation. Using a separate canvas then render to image is a bit more slow and it looks like using pixmap is a bad idea for that kind of thing (have not tried).
    Can I draw points to the screen faster? (I remember when writing the same on a 486 with C. Drawing points directly to the VRAM was way faster than calculating them!)
    In mx2, writing the color index to an array is reasonably fast, but then drawing it to the screen takes more or less then same time than calculating Julia’s iterations!


    Edit: .monkey2 files are blocked for upload for security reasons…


    Mark Sibly

    Had a quick go at speeding this via render-to-pixmap and it’s not bad – was going 22FPS-ish, now does 60 if the mouse is at the edges!

    A bit of hackery involved – it draws directly to a pixel ‘ptr’ instead of SetPixel( x,y ) so it’s not recalculating pixel address all the time.



    wow! now running at 30fps with FullHD on the edges!

    Thanks for that. It shows how pointers are powerfull and is a great lesson.
    I will need some time to understand all of that well. Especially the Cast operator that let you use p as an array. Is that some kind of pointer arithmetics?

    I will have to try some simple examples to get that part.


    Simon Armstrong

    I was interested to see if there was any difference between float and double. I replaced all “Float” with “F” and tried both Alias F:Float and Alias F:Double but could not discern any difference. I suppose under the hood this only affects storage times not calculation times.


    Mark Sibly

    > Especially the Cast operator that let you use p as an array. Is that some kind of pointer arithmetics?

    Since pixels can be stored in a number of different formats, PixelPtr just returns a general purpose ‘UByte Ptr’ and leaves it up to you to cast it to the correct type (if you need to).

    Our pixels are UInts, so the cast converts this to a ‘UInt Ptr’. It’s still just a pointer though, and it will have have the same value. It’s just that when you do math with it (eg: index it with the [] operator, or add/subtract to/from it) the fact the pointer is a ‘UInt Ptr’ will be taken into account. For example, p+=1 where p is a ‘UInt Ptr’ will actually add 4 to p, because UInts are 4 bytes long.



    I continued a bit on this exercise and had the flowing conclusions:

    -as Simon said Float or Double doesn’t change anything (due to 64bit CPU?)

    -Struct is making things slower (made a complex struct based on Vec2)
    One thing about that is that setting a Field directly is (much) faster than setting via Properties.
    So why would we use such properties if it is only to get and set the field the same way it would be done directly?

    I made a github repo for my further exercices and posted the two julia versions on it…



    So why would we use such properties if it is only to get and set the field the same way it would be done directly?

    If you just want to set a field, without the need to get
    the class/object noticed about the change, you can just
    use fields directly.
    But, such fields are always read+write, so for a read-only field
    you need to use a property.

    You would do a field like ‘Window.Title’ (String) as Property,
    because just setting the string is often not enough.
    The property calls an OS/API function like SetWindowTitle()
    in the background if you change win.Title – so that’s where
    you want to use Properties.
    Or setting win.X really moves a window on desktop, because of
    property-internal OS-calls. Just setting an Int value would not
    magically move the window.

    For structs that just hold plain/simple public data (like Matrix),
    you could just use plain fields, most of the time.



    Here’s the most optimized I could find, if anyone see something to be done for optimization welcome!
    I tried a bit to use RGB24 for the pixmap but don’t understand how to get a pointer of that length. But I suppose it won’t change anything with speed or may be worse.
    It can zoom and move and save the picture now. Can we set the png quality for pixmap saving? It does not have the exact same look when saved.



    When i was into Julia, i followed this route: a) find a fast formula, b) optimise the code, c) take advantage of symmetry, d) utalise multithreading, e) go with a pixel shader.

    And i always liked them with colour cycling. :O)

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.