Screen update slow, animation player ALT-A, files created with 2.4x #22685

New Issue

Alan Taylor · 2010-06-28T09:17:09+02:00

Alan Taylor commented

2010-06-28 09:17:09 +02:00

%%%Mac OS X 10.5.8 / PowerBook G4 / Mobility Radeon 9700M
Windows XP / Dell Latitude E5500 / Mobile Intel 4 Series Express Chipset Family

Tested with 2.49b (both), 2.5A2 official release (both), SVN 29759 (Mac), SVN 28577 (Windows)

Screen update speed after ALT-A is around an order of magnitude better with 2.49b in comparison with 2.5, regardless of display setting (bounding box, wireframe or solid). This appears (to my eye anyway) to principally afflict files originally authored with the 2.4 series (as was the file attached).

Examples (with the attached file, solid view):

SVN 29759 (Mac) 0.49FPS reported, 2.49b (Mac) around 10FPS
SVN 28577 (Win) 1.4FPS reported, 2.49b (Win) around 15FPS

The slow (around 1FPS) frame rates apply even using bounding box view.

In all cases the display is very quick to update and completely interactive when manually manipulating the view, whether using wireframe or solid view in either 2.5 or 2.49.

%%%

%%%Mac OS X 10.5.8 / PowerBook G4 / Mobility Radeon 9700M Windows XP / Dell Latitude E5500 / Mobile Intel 4 Series Express Chipset Family Tested with 2.49b (both), 2.5A2 official release (both), SVN 29759 (Mac), SVN 28577 (Windows) Screen update speed after ALT-A is around an order of magnitude better with 2.49b in comparison with 2.5, regardless of display setting (bounding box, wireframe or solid). This appears (to my eye anyway) to principally afflict files originally authored with the 2.4 series (as was the file attached). Examples (with the attached file, solid view): SVN 29759 (Mac) 0.49FPS reported, 2.49b (Mac) around 10FPS SVN 28577 (Win) 1.4FPS reported, 2.49b (Win) around 15FPS The slow (around 1FPS) frame rates apply even using bounding box view. In all cases the display is very quick to update and completely interactive when manually manipulating the view, whether using wireframe or solid view in either 2.5 or 2.49. %%%

Alan Taylor commented

2010-06-28 09:17:09 +02:00

Changed status to: 'Open'

Matt Ebb commented

2010-06-29 08:14:28 +02:00

%%%Intel graphics card is a likely culprit. Please try the other window draw methods available in User Preferences->System and see how that goes.%%%

Alan Taylor commented

2010-06-29 10:20:03 +02:00

%%%The principle machine I use for design (on which I noticed the issue) is the PowerBook G4 which has an 128MB ATI Radeon 9700M card. I just used the Dell for a quick double check.

ATI Mobility Radeon 9700:

Chipset Model:	ATY,RV360M11
Type:	Display
Bus:	AGP
VRAM (Total):	128 MB
Vendor:	ATI (0x1002)
Device ID:	0x4e50
Revision ID:	0x0000
ROM Revision:	113-xxxxx-145
Displays:

Color LCD:

Resolution:	1440 x 900
Depth:	32-Bit Color
Core Image:	Hardware Accelerated
Main Display:	Yes
Mirror:	Off
Online:	Yes
Quartz Extreme:	Supported
Built-In:	Yes

Display Connector:

Status:	No Display Connected

I did exercise the basic steps regarding the window draw method on both machines before filing the report; none of the changes made any noticeable difference regarding frame rate.

Both machines exhibit fast redraw everywhere, except during animation playback.

I've attached another test file; a variant of the original file that's more efficient (less vertices, arrays used for duplication). With this new file on the Mac, at best I get 1.5FPS with 2.5 releases (solid/wireframe/bounding box), still 5x slower than 2.49b with the original file.

Playback speed seems fine on files I've created with 2.5, where I tend to get around 10FPS for scenes with complex geometry with solid/wireframe and 24FPS with boundary box in almost all cases - I have plenty more test files if you want them.

%%%

%%%The principle machine I use for design (on which I noticed the issue) is the PowerBook G4 which has an 128MB ATI Radeon 9700M card. I just used the Dell for a quick double check. ATI Mobility Radeon 9700: ``` Chipset Model: ATY,RV360M11 Type: Display Bus: AGP VRAM (Total): 128 MB Vendor: ATI (0x1002) Device ID: 0x4e50 Revision ID: 0x0000 ROM Revision: 113-xxxxx-145 Displays: ``` Color LCD: ``` Resolution: 1440 x 900 Depth: 32-Bit Color Core Image: Hardware Accelerated Main Display: Yes Mirror: Off Online: Yes Quartz Extreme: Supported Built-In: Yes ``` Display Connector: ``` Status: No Display Connected ``` I did exercise the basic steps regarding the window draw method on both machines before filing the report; none of the changes made any noticeable difference regarding frame rate. Both machines exhibit fast redraw everywhere, except during animation playback. --- I've attached another test file; a variant of the original file that's more efficient (less vertices, arrays used for duplication). With this new file on the Mac, at best I get 1.5FPS with 2.5 releases (solid/wireframe/bounding box), still 5x slower than 2.49b with the original file. Playback speed seems fine on files I've created with 2.5, where I tend to get around 10FPS for scenes with complex geometry with solid/wireframe and 24FPS with boundary box in almost all cases - I have plenty more test files if you want them. %%%

Diego Borghetti commented

2010-06-29 20:04:40 +02:00

%%%Hi,

This seems to be more a limit in the graphics card, with a Nvidia 8600 GT I get 4/5 fps and with a nvidia GTS 250 12/13 fps.

So I think is not really a bug, yes the code of Modifiers maybe need a optimization, but that don't count as bug, maybe something to move to the wiki ?

hmhm both modifier don't have any important change so, probably this is because the new draw system of Blender.

Matt, what do you think ?

Diego%%%

%%%Hi, This seems to be more a limit in the graphics card, with a Nvidia 8600 GT I get 4/5 fps and with a nvidia GTS 250 12/13 fps. So I think is not really a bug, yes the code of Modifiers maybe need a optimization, but that don't count as bug, maybe something to move to the wiki ? hmhm both modifier don't have any important change so, probably this is because the new draw system of Blender. Matt, what do you think ? - Diego%%%

Brecht Van Lommel commented

2010-06-29 20:14:24 +02:00

%%%In the first .blend file, only the location of the objects is animated, but the modifiers are being re-evaluated each frame, this should not be happening.%%%

Matt Ebb commented

2010-06-30 13:35:58 +02:00

%%%After a bit of fiddling around I think OB_RECALC_DATA is being set for these objects in the depgraph, but I haven't found where yet, still looking..%%%

Matt Ebb commented

2010-07-01 05:06:58 +02:00

%%%Well, i hunted this for a very long time, and found the culprit:

depsgraph.c line 2035:

if(animdata_use_time(ob->adt)) {
ob->recalc |= OB_RECALC;
ob->adt->recalc |= ADT_RECALC_ANIM;
}

I believe line 2036 should be changed to OB_RECALC_OB - OB_RECALC is the added bitflags OB_RECALC_OB, OB_RECALC_DATA, OB_RECALC_TIME, but we don't need to recalc the obdata if there is only animation on the object AnimData.

So I'm guessing this is a typo, unless there is some other reason for this - perhaps animated modifier properties need this if the rna paths fall under Object AnimData ? in that case, it might be better to do this separately, perhaps in the modifier_dependsOnTime callbacks...

As a side note, it might be a good idea to rename the define OB_RECALC to OB_RECALC_ALL, since i'm wondering if it's been used by mistake in other areas of the code, thinking it just recalculates the object itself.

Anyway, assigning to Joshua to check this out!%%%

%%%Well, i hunted this for a very long time, and found the culprit: depsgraph.c line 2035: if(animdata_use_time(ob->adt)) { ob->recalc |= OB_RECALC; ob->adt->recalc |= ADT_RECALC_ANIM; } I believe line 2036 should be changed to OB_RECALC_OB - OB_RECALC is the added bitflags OB_RECALC_OB, OB_RECALC_DATA, OB_RECALC_TIME, but we don't need to recalc the obdata if there is only animation on the object AnimData. So I'm guessing this is a typo, unless there is some other reason for this - perhaps animated modifier properties need this if the rna paths fall under Object AnimData ? in that case, it might be better to do this separately, perhaps in the modifier_dependsOnTime callbacks... As a side note, it might be a good idea to rename the define OB_RECALC to OB_RECALC_ALL, since i'm wondering if it's been used by mistake in other areas of the code, thinking it just recalculates the object itself. Anyway, assigning to Joshua to check this out!%%%

Alan Taylor commented

2010-07-01 12:15:15 +02:00

%%%Deleting the curves in the graph editor so the positions are no longer animated, returns the frame rate to where it should be (around 10FPS)

Adding them back, one object at a time, gradually slows the frame rate back to 0.5FPS.%%%

%%%Deleting the curves in the graph editor so the positions are no longer animated, returns the frame rate to where it should be (around 10FPS) Adding them back, one object at a time, gradually slows the frame rate back to 0.5FPS.%%%

Joshua Leung commented

2010-07-05 05:54:29 +02:00

%%%As I mentioned to Matt earlier on IRC, there are a few things here:

Indeed I've been confused into thinking that OB_RECALC only recalculated the object on a few occasions (I think I even did that in soc branch recently too). So, that should get renamed (to OB_RECALC_ALL) for clarity
In the case of modifiers, we need to keep in mind that they may be animated, in which case the animdata check would apply too, since modifiers are animated by animdata on object level.
Perhaps we could add separate checks for whether modifiers need time-based updating due to animation...

I've made these changes in svn, so this bug should be able to be closed. To avoid introducing new bugs at the same time, I've avoided making other changes elsewhere, but we should double check some of the places in the commit where OB_RECALC_ALL is now used to check for those mistaken usages. %%%

%%%As I mentioned to Matt earlier on IRC, there are a few things here: - Indeed I've been confused into thinking that OB_RECALC only recalculated the object on a few occasions (I think I even did that in soc branch recently too). So, that should get renamed (to OB_RECALC_ALL) for clarity - In the case of modifiers, we need to keep in mind that they may be animated, in which case the animdata check would apply too, since modifiers are animated by animdata on object level. - Perhaps we could add separate checks for whether modifiers need time-based updating due to animation... I've made these changes in svn, so this bug should be able to be closed. To avoid introducing new bugs at the same time, I've avoided making other changes elsewhere, but we should double check some of the places in the commit where OB_RECALC_ALL is now used to check for those mistaken usages. %%%

Joshua Leung commented

2010-07-05 05:54:30 +02:00

Changed status from 'Open' to: 'Resolved'

Joshua Leung closed this issue

2010-07-05 05:54:30 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Screen update slow, animation player ALT-A, files created with 2.4x #22685