It's probably a combination of cairo/pixman/gdk_pixbuff that is interacting weirdly with Pat's Mac. I'll test it with him to see what the cause is. On Fri, Jul 12, 2013 at 6:15 PM, Michael Henning <drawoc@xxxxxxxxxxxxxxxxxx>wrote: > The warning that said "'Geglconfig" has no property named > 'cache-size'." isn't related. That's just there because of the version > of gegl in use by the builds. > > Because 2.8 doesn't use gegl for most operations, that wouldn't cause > your issue. > > Sorry, I don't know what's causing this. > > -- drawoc > > On Thu, Jul 11, 2013 at 10:41 PM, Pat David <patdavid@xxxxxxxxx> wrote: > > To follow up, in case it helps anyone out, here is the output from the > > terminal when running the app: > > > > Pats-Air:MacOS pat$ ./Gimp > > Dir is . > > Appdir is /Users/pat/Downloads/Gimp-2.8.app > > removed /tmp/pb2.8 folder > > removed tmp/lib folder > > Hello - About to run Gimp - Standby > > CWD is /tmp/pb2.8/Gimp-2.8.app/Contents/MacOS > > pwd is /Users/pat > > Strip out the argument added by the OS... > > Cannot spawn a message bus without a machine-id: Unable to load > > /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file > > '/var/lib/dbus/machine-id': No such file or directory > > > > (gimp-2.8:6567): GLib-GObject-WARNING **: g_object_set_valist: object > class > > 'GeglConfig' has no property named 'cache-size' > > > /tmp/pb2.8/Gimp-2.8.app/Contents/Resources/share/gimp/2.0/themes/Small/gtkrc:18: > > Unable to locate image file in pixmap_path: > > "../Default/images/stock-error-64.png" > > > /tmp/pb2.8/Gimp-2.8.app/Contents/Resources/share/gimp/2.0/themes/Small/gtkrc:22: > > Unable to locate image file in pixmap_path: > > "../Default/images/stock-info-64.png" > > > /tmp/pb2.8/Gimp-2.8.app/Contents/Resources/share/gimp/2.0/themes/Small/gtkrc:26: > > Unable to locate image file in pixmap_path: > > "../Default/images/stock-question-64.png" > > > /tmp/pb2.8/Gimp-2.8.app/Contents/Resources/share/gimp/2.0/themes/Small/gtkrc:30: > > Unable to locate image file in pixmap_path: > > "../Default/images/stock-warning-64.png" > > ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow) > > ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible) > > ** Message: pygobject_register_sinkfunc is deprecated (GtkObject) > > > > ** (process:6580): WARNING **: Trying to register gtype > 'GMountMountFlags' > > as enum when in fact it is of type 'GFlags' > > > > ** (process:6580): WARNING **: Trying to register gtype > 'GDriveStartFlags' > > as enum when in fact it is of type 'GFlags' > > > > ** (process:6580): WARNING **: Trying to register gtype 'GSocketMsgFlags' > > as enum when in fact it is of type 'GFlags' > > > > > > The only part that looks possibly suspect/related to me is the > > GObject-WARNING about 'Geglconfig" has no property named 'cache-size'. > > > > Could this be related? > > > > > > > > On Mon, Jul 8, 2013 at 8:40 AM, Pat David <patdavid@xxxxxxxxx> wrote: > > > >> Hi all, > >> > >> I wasn't sure if I should post here, but I figure it can't hurt. > >> > >> I'm running OSX 10.7.5 (Lion) w/ 4GB ram, and have been primarily using > >> two builds from Simone and Partha. (Partha's 2.8.6 build, and the > latest > >> from Simone for Lion 2.8.4 - 2.8.4p2) > >> > >> What I'm seeing is an incredibly slow screen/canvas redraw when doing > >> actions that affect the entire layer. For instance, here is a small > >> screencast of turning a layer on and off in my system: > >> > >> http://www.youtube.com/watch?v=dxLlOJY7ZJs > >> > >> I've tried setting the tile cache size from 3GB to 1GB, and even down to > >> 512MB, but it makes no difference. > >> > >> I've found previous posts around about color management possibly being > the > >> culprit, but I've tried it both with/without color management enabled, > and > >> it appears to make no difference. > >> > >> The only thing I've noticed is that if I zoom into a much smaller > region, > >> things speed up quickly. (It's actually faster to zoom in to about > 300%, > >> toggle a layer visibility or adjust curves, then zoom out - where the > >> effect has been applied across the entire image layer, as opposed to > trying > >> to do while viewing the entire image). > >> > >> I saw a changelog that mentioned this might be fixed, so I'm worried I > >> might be doing something wrong... > >> > >> -- > >> pat david > >> http://blog.patdavid.net > >> > > > > > > > > -- > > pat david > > http://blog.patdavid.net > > _______________________________________________ > > gimp-developer-list mailing list > > List address: gimp-developer-list@xxxxxxxxx > > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@xxxxxxxxx > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
