After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 339895 - [Advanced Timeline] Zooming in too much causes X error
[Advanced Timeline] Zooming in too much causes X error
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: User interface
Git
Other Linux
: Normal normal
: 0.11.2
Assigned To: Pitivi maintainers
Pitivi maintainers
: 424983 457142 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-04-27 09:54 UTC by Edward Hervey
Modified: 2008-10-11 10:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2006-04-27 09:54:17 UTC
When zooming in a lot, X raises the following error :
The program 'pitivi' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 277724 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

The problem would be that we are requesting a much too big area for the timeline widget ('BadAlloc (insufficient resources for operation)')

We need to limit the requested size in some way.
Comment 1 Edward Hervey 2006-05-16 08:32:53 UTC
We in fact need to limit zooming in/out to sensible values:

* Zooming in : seeing frames over more than 100 pixels seems.... excessive (2500 pixels for a second).
We need to think about why people would want to zoom in as much. Once we have complete thumbnailing, the sensible choice would be to enable the users to see each frame completely. So <thumbnail-width + borders> for a frame seems sensible.

* Zooming out : one hour for 100 pixels seems good enough (for a 1280 width screen, that would enable seeing 12hours in a go).
Comment 2 Chris Van Patten 2006-08-17 21:19:00 UTC
Here's what I know from my experience:

Maximum zoom in level should be 1 full frame wide (across the whole screen).  That seems a bit excessive, but you will find that there are always going to be users asking to be able to zoom in further.  If you have it so you can zoom up to 1 full frame you cover everyone.  At this zoom level, you should be able to move to the right or left (forward and back, respectively) by half frames.  That way you might have two half frames in your screen (which ultimately make up one whole frame).  Perhaps this could be a variable in options.

Maximum zoom out level should be the whole project (the entire length that video or audio goes) plus 1/3 that total length.  For example, if all the audio and video runs 66 minutes long, the timeline would zoom out to the maximum of showing 99 minutes.  At default though, when no video is in the project, it should default to 3 hours (180 minutes).

Thats just my opinion though and my opinion changes a lot.  I'll play around with Sony Vegas Movie Studio some more to get a feeling of how that works and report back.
Comment 3 Edward Hervey 2007-04-17 08:47:20 UTC
*** Bug 424983 has been marked as a duplicate of this bug. ***
Comment 4 Edward Hervey 2007-07-24 17:11:16 UTC
*** Bug 457142 has been marked as a duplicate of this bug. ***
Comment 5 Edward Hervey 2008-10-11 10:39:17 UTC
Fixed in 0.11.2 due to brandon's goocanvas timeline and some other fixes in the ruler.