Drawing Arcs - Hewlett Packard

This is a discussion on Drawing Arcs - Hewlett Packard ; > 30px, Quarter Circle: 25ms > 30px, Half Circle: 26ms > 30px, Full Circle: 30ms > 60px, Full Circle: 33ms > 150px, 3/4 Circle: 41ms > > Much faster than my SysRPL program :-), congratulations on your > incredible success. ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 43 of 43

Thread: Drawing Arcs

  1. Re: Drawing Arcs

    > 30px, Quarter Circle: 25ms
    > 30px, Half Circle: 26ms
    > 30px, Full Circle: 30ms
    > 60px, Full Circle: 33ms
    > 150px, 3/4 Circle: 41ms
    >
    > Much faster than my SysRPL program :-), congratulations on your
    > incredible success.


    Indeed that it is very good. Now the next step is to do it in ARM ASM
    or in HPGCC. I have an HPGCC routine around here somewhere that does
    something like 500-1K arcs a second and it was not very good code.

    TW

  2. Re: Drawing Arcs

    On Aug 14, 10:08 pm, Yann wrote:

    > Thanks to Cyrille's "nibble traveler" methodology, which avoids
    > calculating memory pixel location, performance are good.
    > As a funny side effect, now the program spends more time in the header
    > than drawing the arc. This was tested with the "PureCode" version,
    > which removes the header, and it resulted in 31ms being spent on
    > header alone (on GX), which means twice more time than is necessary to
    > draw a 30pixels half-circle on the same platform.
    > Of course, performances on newer platform should be even better.
    >


    TEVAL gives timings of 32-48 ms for me for your test cases on the 50g.

    (These were full version tests, not PureCode tests)

    A few larger scale testcases:
    <<50000 50000 20000 0 180 fastarc>> 3.16 seconds
    <<50000 50000 20000 0 360 fastarc>> 4.34 seconds
    <<50000 50000 20000 180 360 fastarc>> 2.04 seconds

    (the timing discrepancy between the first and last of those is
    surprisingly large, considering both are half arcs of the same radius
    and center point)

    For all reasonable sized circles the results seem instant.

  3. Re: Drawing Arcs

    Thanks for the feedback, i'm glad if it pleases you and can be of any
    use.

    Just some answers to latest comments :

    - Discrepancy : there is a side-effect to the "nibble traveller"
    methodology : it avoids calculating the memory position for each
    pixel, but it needs a start point. This start point has been hardcoded
    at position 90. Therefore, if you start from position 0, you have a
    worse performance penalty than starting from 180.
    This could be improved, with a bit of logic, to start immediately to
    the right octant, something i did for the older code.
    But then, this would result in quite a bit more logic, creating havoc
    in the carefully designed register allocation, increasing complexity &
    code size, therefore i started to wonder if it was really necessary to
    be "even more faster" at such a cost.
    In the end, i decided to keep code length & complexity as low as
    possible. But this, of course, can be changed if someone find it
    necessary.

    Note that, in your example, an even better solution would be to
    discard undrawn quarters (or octants). Because these huge arcs are
    "out of screen", not even drawn, this would result in an almost
    immediate discarding. Here also, adding this bit of logic is not
    hugely complex, but is bound to increase code size and create
    complexity. Well, anyway, if there is a need for this, then why not,
    this can be done.

    - HPGCC (TW) : it is my long-term intention to move to ARM ASM some
    day; For the time being, i'm merely learning ASM as an entertaining
    exercise, and i find it more attractive to develop for my "old"
    hardware student's calc, an HP48SX. The reasoning is : if it is fast
    and usable enough for 48SX, then newer model will only find it even
    better. For sure, there is a limit, but i'm not yet good enough to
    cross through it.

    As a sidenote, note that Circle code is quite simpler to do than Arc.
    As an example, i've got a quick version of Fastcircle, derived from
    Cyrille de Brebisson example with a Breisenham cache, which only needs
    30ms to draw a full circle on HP48SX, including header. This is nearly
    three times faster than Arc, because it is so much simpler to process.


    Well, I guess the next step is to submit the FastArc program software
    to HPCalc.org, so that anyone interested can get it in the future.

    Regards

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3