ArtRage 5 Product PageArtRage Lite Product PageArtRage for iOS Product PageArtRage for Android Product PageArtRage  Android Oil Painter Free Product PageArtRage  Free Demos Page

Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Performance Issues

  1. #1

    Performance Issues

    I apologize if this has been addressed before, however I searched the forums for all performance and CPU related issues and was unable to find anything similar to the issues that have been troubling me. I am hopeful that this is simply a configuration issue, or that a workaround exists, as it is making ArtRage nearly impossible for me to continue using.

    As I read through some of the other posts I noticed that fans of ArtRage are quick to try to debunk all claims of a slowdown. The enthusiasm is great, but please keep in mind that I am experiencing a very frustrating problem and I have done my best to 'quantify' the problem and simply want suggestions, and ultimately, a fix. Having a list of people who don't have the problem won't make me feel any better.

    1. The only program running is ArtRage 2.5 (and in later tests, both Artrage 2.5 and alias sketchbook 2.0 were open so that I could compare performance).
    2. Create a new painting, using the default settings: 1024 x 738 @ 72 DPI.
    3. Select the pencil tool and reset to defaults (though all tools are affected).
    4. Use a mouse, or the pen/tablet – it will not matter.

    Having this baseline setup I began looking for a pattern and immediately came to notice that ArtRage has no problems with short strokes. However, anything longer than a quick scratch, and it appeared as though the software couldn’t keep up. I then launched task manager so that I could confirm the changes in CPU usage while testing.

    The CPU quickly maxes out when I begin drawing, and anything over a half second or so is enough for the performance monitor to register Artrage as maintaining a 99% load. To my surprise, I found that movement is not a factor in the slowdown – slow circles, long sweeping movements, and even dots (holding down the mouse button or touching the pen to the tablet) will all max out the CPU at the same rate.

    I know it seems strange, but I felt I should test Sketchbook Pro 2.0 help eliminate any question as to whether it was hardware or operating system related. Sketchbook was able to perform the very same pencil related tasks while utilizing less than 5% of the processor.

    I am running Windows Vista on a high end Lenovo x60 Tablet with 2 gigs memory and intel core 2 duo @ 1.8 Ghz. I am able to reproduce this bug without fail and will be happy to work with you to provide you with as much information as you need to eliminate this problem.

    Thanks,

  2. #2
    Join Date
    Mar 2006
    Location
    Ambient Design
    Posts
    3,839
    When you say the software can't keep up, what is it you're seeing?

    ArtRage is a very different application to Sketchbook in several ways. Firstly, ArtRage uses about 3 times the amount of memory to represent each pixel in your canvas. As well as colour information there is the depth of paint, the wetness of the paint, the shine of the paint, and how reflective it is. As we're compositing against a separate paper texture we also need to keep the alpha of the paint at each pixel.
    Once the paint is applied to the canvas it then has to be run through a 3D lighting renderer to get the natural look and feel of the paint. The 3D rendering is very CPU intensive.
    However, we do a number of things to keep the painting process responsive. When you're doing a long fast stroke we reduce the number of updates - we can do more efficient rendering if we assume we're going to render a bigger chunk, and do a large update, than if we constantly render small chunks and update constantly. So if it appears on a fast stroke the update lags your brush slightly, it could be that we're just increasing the granularity of updates to get faster rendering performance.

    Ignore the CPU usage indicator - it's not a true indication of the way ArtRage works. During a stroke we reserve all the idle processing unless something else wants it - it doesn't mean we're actually using it. (This will likely change in a future version of ArtRage as it does lead to confusion).

    However if you're seeing a long delay between stroke and update it could be something else.
    2GB is a decent amount of memory - it sounds like your machine specs are completely adequate for ArtRage. Hell, we get good performance on a 800MHz compuer with 1GB Ram.
    AndyRage's mantra for graphics engine code:
    "Sure - how hard can it be?"

  3. #3
    As a software developer, I know that suggestions how 'helpful' suggestions can be when made by people who have not seen the code. Unfortunately, the best way that I can describe the performance problems would be to compare them to problems I have encountered in the past – and I would best liken it to situations where the program in question is fighting with vital windows threads for processing resources. There are a couple of things that I see that support this observation, but I could be way off…

    To clarify, I will try to use the terms quick/slow as a time indicator, and short/long to describe the distance covered in the stroke.

    There are two main symptoms that concern me:
    1. The rendering of a stroke appears to lag behind the actual stroke – short strokes have the same problem, however the problem is more pronounced in longer strokes with quick movements. In most cases this is not a deal breaker and would be classified as an annoyance, but when it comes to trying to trying to sketch or shade it becomes extremely difficult to work with.
    2. When trying to shade, for example quick and short strokes used in cross hatching, many strokes simply fail to be recognized and are discarded.

    Here is an example that will allow you to reproduce what I believe to be just one symptom of this faulty behavior.
    1. Start task manager or another performance profiler
    2. Launch ArtRage 2.5
    3. Create a new painting
    4. Check the profiler and verify that the application uses very little CPU time.
    5. You can select any tool, but for this test, select the pencil.
    6. Using your mouse, move your cursor to the center of the screen.
    7. Press and hold the left mouse button. Do not move the cursor.
    8. Check the profiler and you will see that the processor is maxed out.
    9. Release the mouse button and look at the very tiny dot that your slow short stroke produced.
    10. Check the profiler and see that the processor returns to idle speeds immediately after the left mouse button is released.

    Do I think that it is a memory problem? No, when using the settings listed in my previous post, ArtRage allocates around 32 megabytes. (In comparison, Alias Sketchpad pro 2.0 uses around 20 megabytes.)

    Do I think that it is a rendering problem? No, the renderer works fine. In fact, even if I finish ridiculously slow and long strokes, as soon as I release the input the renderer catches up and the CPU returns to idle. If the renderer (and all the work the renderer must do) were the cause of this problem; and, if the renderer was trailing my pen tip by 2 or 3 seconds, it should still take 2 or 3 seconds to catch up after lifting the pen off of the tablet. However, as soon as I lift the pen, the renderer catches up instantly and the CPU returns to idle speed.

    The only logical conclusion I can come up with is that because the latency only builds up when the pen is writing, this problem is tied to how the user input is gathered. If I were to make an educated guess based on your explanation and the symptoms, I would guess that once a pen/mousebutton down event is processed the program enters a while loop for gathering user input.

    (The only other possibility that I can think of is that for some odd reason the application is processing redundant input events – but even in that scenario, the system should have a chance to catch up after each message is processed, and I wouldn’t expect the latency issues to be so pronounced.)

    Will you please check to make sure that ArtRage is not processing redundant events, as well as see what it would take to add a way to change input resolution? Perhaps allowing users to configure the maximum number of input queries allowed to be processed each second. If you were to add this ability with a default of infinite, existing users wouldn’t notice any difference at all.

    If my suggestions do not help, please let me know what information i can give you that will.

    Thanks,

  4. #4
    Join Date
    Mar 2006
    Location
    Ambient Design
    Posts
    3,839
    Ignore the CPU indicator - it's not correctly representing what is actually occurring with ArtRage.

    When you mouse-up with the stylus, ArtRage changes rendering mode from interactive to 'just finish the thing as quickly as possible' mode.

    I just had a thought - check your ArtRage menu for Edit/Preferences, and change the 'Precise tablet mode' setting. Tell me if that makes a difference to the apparent responsiveness of fast shading strokes.
    AndyRage's mantra for graphics engine code:
    "Sure - how hard can it be?"

  5. #5
    I truely appreciate your responding to my questions and concerns. Would it be better to continue this conversation privately?

    I turned off the precise tablet mode and didn't notice much effect on responsiveness - however, every single line now appears to have a hook added to the front of it. The hook won't do so I turned the precise mode back on.

    Ignore the CPU indicator - it's not correctly representing what is actually occurring with ArtRage.
    This greatly confuses me. While it may not explain what is happening within ArtRage, it does explain how the "interactive mode" is affecting the operating system and hardware while the pen is active. I have two questions that might help me understand where you are comming from on this:

    1. Is it intentional that the software maxes out the CPU when the pen is active?

    2. Should it max out the CPU even when the pen is active and is not moving? In other words, the pen is active only in the sense that it is on the surface - it is not moving, input events are not being fired (i hope), and there is nothing new to render to the image. I am isolating this question to tools that I believe require movement across a surface, like a pen or pencil. This assumption would not be valid for tools with an additive effect, like a spray can.

    Even if the CPU issue is not the cause of my original problems, it is something I strongly urge you to consider revising as it has other adverse side effects on a mobile device (such as reducing battery life and excess heat).

  6. #6
    Join Date
    Mar 2006
    Location
    Ambient Design
    Posts
    3,839
    I dont understand why the CPU usage is an issue. In normal usage, you are painting strokes - in which case the CPU would be used while you're making strokes. When you lift your pen, the CPU usage drops.

    FYI we'll be changing the input engine in a later release of ArtRage to give a better stroke interpolation, and at that time we'll likely change to a different processing model for pen events.

    Can you give me a screen shot of the 'hooks' you're seeng on your strokes, and describe the process in detail you're using to make the strokes: Eg: very fast, slow and careful, rapid hatching, sweeping curves, and so on.
    AndyRage's mantra for graphics engine code:
    "Sure - how hard can it be?"

  7. #7
    Well, I start with the processor because the processor is where all the work is done. If the work does not use the CPU to full capacity, the rendered image will follow pen strokes without delay. However, if the work builds up faster than the CPU can process - there will be 'lag' between the pen strokes and the rendered image. In this case, the latency issues presented themselves and in order to help you track it down I gathered whatever information I could.

    While this is a simplification of actual problems, you can figure out a great deal on what is causing latency issues by traversing system performance logs. If there were system deadlocks the ArtRage would share the CPU load with another process. If the input device hardware could not keep up with Artrage, the CPU would idle while waiting on callbacks. Often the most simple explanation is the correct explanation... too much work is being generated and the processor cannot keep up.

    Do I know for sure that there is too much work? No. This is why I asked those 2 specific questions - I wanted to know if there is too much work being generated and whether it is intentional. Because you did not answer those questions I still do not know whether it is an issue that is isolated to my system, or whether it is behaving as intended, or whether it is a bug that is going to be fixed.

    All I know for sure is that I can build up a great deal of latency (as well as max out my CPU) by simply holding my mouse button down. This scenario should not produce any work, nor does it affect the resulting image. This tells me that ArtRage is processing a great deal of work that does not acommplish anything. This also tells me that (on my system) it does not matter whether a pen stroke covers the entire canvas, or a tiny fracton of it, the latency is generated based on the time the pen is held to the canvas. In effect, when the pen is down, Artrage produces as much work as it can - even if the work accomplishes nothing.

    Are these valid observations? You tell me... All I know is that I need a resolution to this problem and all that we have accomplished was finding an additional problem.

    Speaking of the other problem, I have included an image that shows the hooking problem. The hooks appear at the start of the stroke and will be quite obvious when you see the image. The pencil strokes on the left show the hooking. The pencil strokes on the right are the 'same' strokes with the precise tablet mode enabled. The strokes on the top half of the screen were made with the pencil tool, and the bottom with the pen. The speed of the stroke only changes the length of the hook, so all strokes were made at a speed that made the hooks easy to see.
    Attached Images Attached Images

  8. #8
    Join Date
    Mar 2006
    Location
    Ambient Design
    Posts
    3,839
    Okay, great - thanks for the screen shots.
    On an InkServices-enabled device (eg: Tablet PC with XP for TabletPC, or Vista with InkServices enabled) we use either mouse coordinates, or raw tablet packets (precise tablet mode). With the raw tablet packets we get floating-point precision on mouse coordinates. However on some systems the raw tablet packets dont conform exactly to the 'standard' process, so they may be relative to the screen, or relative to the window, or scaled to a different space. This is why we offer the non-precise tablet mode - mouse coordinate are always correct for the display, but they're only integer precision.
    On an Ink-services enabled system the mouse coordinates can 'lag' the other information that's coming in - eg. pressure, tilt and orientation. The reason for this is that behind the scenes the InkServics is checking for right-click assistance, gestures, press-and-hold enablers and the like. So there's a small threshold of movement before a movement with a stylus registers.
    So when ArtRage receives tablet packet information saying pressure is applied, but the coordinates are going through the mouse coordinate system, we start processing the stroke event while the prevous mouse coordinates are still coming in.
    It sounds a bit cludgy - I know. There's no standard API for getting floating-point accurate coordinates, with information as to whether they're coming from a pressure-enabled device. So we try various 'tricks' to determine whether a stroke is happening. Anyway, we keep refining it, so I'm sure it'll be even better in the next version of ArtRage. In the meantime, if precise-coordinates work best for you, use them.
    AndyRage's mantra for graphics engine code:
    "Sure - how hard can it be?"

  9. #9
    Join Date
    Aug 2007
    Location
    USA
    Posts
    12
    Hello Damagetime

    I was wondering if you could look at my post "It's a real drag! Brushes trail behin cursor." and tell me if you think your proplems are similar?

    Thanks
    RachelRock

  10. #10
    Join Date
    Jul 2006
    Location
    Johannesburg, South Africa
    Posts
    218
    Hiya guys...

    Firstly... I want to add my voice of praise to this release. It kicks all butt.

    Secondly... I'd like to add a note to DamageTime's observations.

    I think I've noticed something that MIGHT be related, and it's almost certainly a minor bug, and probably quite easily sorted (says Roy, the non-programmer -- hehehehehehe).

    The problem I'm noticing is specifically related to quick multiple strokes. Here's how it manifests....

    Say I'm using a thinnish paint brush, on a 2500 x 2000 pixel pic. Say I'm doing quick, short, 'attack-the-canvas' kinda scribble-painting.

    I find that the first time I put the stylus on the screen, ArtRage 'sees' this as a stroke. The next time I place the stylus, ArtRage doesn't 'see' this, and no stroke is made.

    The way it 'feels' to me as a user is that ArtRage isn't releasing the stylus in time to make the next stroke.

    There is an allied (or shall I say, POSSIBLY allied) behaviour that I've noticed...

    When I'm erasing with a nice tight closeup on a large canvas, I'll often use the new 'right click' to move the canvas around. Sometimes when I do this, I find an erased dot where I've started the push. It doesn't seem to do it every time, and it 'feels' like it's related, cos it might be only every other stroke. Not sure.

    Re the memory useage...

    I experience exactly what DamageTime is describing. At a certain point in my ArtRage session, my computer will suddenly kick into extreme-resource-utilisation mode. The chip quickly heats to maximum (74 degrees C), and my memory manager tells me that ArtRage is consuming 99% of the resources.

    It feels as though something specific happens to jam up the cache, and then it's kinda jammed. The way I solve it is to save, close ArtRage, open it again, and it's all fine.

    I use a Toshiba Tecra M4, 1.73mHz, 1 gig ram. And I didn't have any of these lag issues with ArtRage 2.2. So it pretty much HAS to be something about the new engine.

    Having said all this, I'm LOVING this version. And I'm sure the niggles will be ironed out.

    Thanks for all the incredible changes.

    Blue skies
    love
    Roy
    ROY BLUMENTHAL

    Visual Facilitator: http://royblumenthal.com/portfolio

    ArtRage 3.5.5 and 4.0.4 on:
    Fujitsu T901, Asus R1E

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •