Re: [clutter] problem with threads and clutter-texture from file: Failed to create COGL texture

2009-12-02 Thread Aapo Rantalainen
2009/12/2 danny tornad...@163.com:
 Your demo program works normally for me.
Thank you very much for this information. I tested this on another
computer and it worked.

So I'm using clutter and threads in right way. (Maybe there should be
little bit more manual than test/interactive/test-threads.c?)


Perhaps it a problem related to others such as VGA driver...
But what next, how I know what is problem with my computer?

Are these information relevant:
Clutter: 1.0.6-0ubuntu1
Linux 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009
x86_64 GNU/Linux

Computer: Lenovo T500
VGA compatible controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)
xserver-xorg-video-intel: 2:2.9.0-1ubuntu2


-Aapo Rantalainen
-- 
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com



Re: [clutter] problem with threads and clutter-texture from file: Failed to create COGL texture

2009-12-02 Thread Emmanuele Bassi
On Wed, 2009-12-02 at 11:27 +0200, Aapo Rantalainen wrote:
 2009/12/2 danny tornad...@163.com:
  Your demo program works normally for me.
 Thank you very much for this information. I tested this on another
 computer and it worked.
 
 So I'm using clutter and threads in right way.

no, you really aren't.

  (Maybe there should be
 little bit more manual than test/interactive/test-threads.c?)

sure; but at least that code shows you how to use threads - and you're
not even close to how test-threads is implemented.

use the :load-async property on ClutterTexture to load data from files
asynchronously using threads.

 
 Perhaps it a problem related to others such as VGA driver...

this sentence doesn't make any sense.

ciao,
 Emmanuele.

-- 
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com



Re: [clutter] problem with threads and clutter-texture from file: Failed to create COGL texture

2009-12-02 Thread Aapo Rantalainen
 but at least that code shows you how to use threads - and you're
 not even close to how test-threads is implemented.

Hi, now I made my test preloader top of test-thread.c
This is diff:
--- old_test-threads.c  2009-12-02 14:53:11.0 +0200
+++ test-threads.c  2009-12-02 15:08:45.0 +0200
@@ -85,6 +85,8 @@
   return FALSE;
 }

+ClutterActor *actor;
+
 static void
 do_something_very_slow (void)
 {
@@ -115,6 +117,13 @@
   clutter_threads_add_idle_full (G_PRIORITY_DEFAULT + 30,
  update_label_idle,
  update, NULL);
+
+GError* error = NULL;
+if (!(actor = clutter_texture_new_from_file(image.png, error))) {
+fprintf(stderr, %s\n,  error-message);
+g_error_free(error);
+}
+
 }
 }
 }
@@ -174,8 +183,7 @@
   return FALSE;
 }

-G_MODULE_EXPORT int
-test_threads_main (int argc, char *argv[])
+int main (int argc, char *argv[])
 {
   ClutterActor *stage;
   ClutterActor *rect;


I only add making actor from file inside thread. (and it can be
compiled stand-alone).

This is whole application:
#include stdio.h
#include stdlib.h
#include gmodule.h
#include clutter/clutter.h

typedef struct
{
  ClutterActor *stage;
  ClutterActor *label;
  ClutterActor *progress;

  ClutterTimeline *timeline;

  volatile gboolean cancelled;
} TestThreadData;

static TestThreadData *
test_thread_data_new (void)
{
  TestThreadData *data;

  data = g_new0 (TestThreadData, 1);

  return data;
}

static void
test_thread_data_free (TestThreadData *data)
{
  g_object_unref (data-progress);
  g_object_unref (data-label);
  g_object_unref (data-stage);
  g_object_unref (data-timeline);

  g_free (data);
}

static gboolean
test_thread_done_idle (gpointer user_data)
{
  TestThreadData *data = user_data;

  g_print (Thread completed\n);

  clutter_text_set_text (CLUTTER_TEXT (data-label), Completed);
  clutter_timeline_stop (data-timeline);

  test_thread_data_free (data);

  return FALSE;
}

static GStaticPrivate test_thread_data = G_STATIC_PRIVATE_INIT;

typedef struct
{
  gint count;
  TestThreadData *thread_data;
} TestUpdate;

static gboolean
update_label_idle (gpointer data)
{
  TestUpdate *update = data;
  guint width;
  gchar *text;

  text = g_strdup_printf (Count to %d, update-count);

  clutter_text_set_text (CLUTTER_TEXT (update-thread_data-label), text);
  clutter_actor_set_width (update-thread_data-label, -1);

  if (update-count == 0)
width = 0;
  else if (update-count == 100)
width = 350;
  else
width = (guint) (update-count / 100.0 * 350.0);

  clutter_actor_set_width (update-thread_data-progress, width);

  g_free (text);
  g_free (update);

  return FALSE;
}

ClutterActor *actor;

static void
do_something_very_slow (void)
{
  TestThreadData *data;
  gint i;

  data = (TestThreadData *) g_static_private_get (test_thread_data);
  if (data-cancelled)
return;

  for (i = 0; i  100; i++)
{
  gint msecs;

  msecs = 1 + (int) (100.0 * rand () / ((RAND_MAX + 1.0) / 3));

  /* sleep for a while */
  g_usleep (msecs * 1000);

  if ((i % 10) == 0)
{
  TestUpdate *update;

  update = g_new (TestUpdate, 1);
  update-count = i;
  update-thread_data = data;

  clutter_threads_add_idle_full (G_PRIORITY_DEFAULT + 30,
 update_label_idle,
 update, NULL);

GError* error = NULL;
if (!(actor = clutter_texture_new_from_file(image.png, error))) {
fprintf(stderr, %s\n,  error-message);
g_error_free(error);
}

}
}
}

static gpointer
test_thread_func (gpointer user_data)
{
  TestThreadData *data;

  data = user_data;
  g_static_private_set (test_thread_data, data, NULL);

  do_something_very_slow ();

  clutter_threads_add_idle_full (G_PRIORITY_DEFAULT + 30,
 test_thread_done_idle,
 data, NULL);

  return NULL;
}

static ClutterTimeline *timeline   = NULL;
static ClutterActor *count_label   = NULL;
static ClutterActor *help_label= NULL;
static ClutterActor *progress_rect = NULL;

static gboolean
on_key_press_event (ClutterStage *stage,
ClutterEvent *event,
gpointer  user_data)
{
  TestThreadData *data;

  switch (clutter_event_get_key_symbol (event))
{
case CLUTTER_s:
  clutter_text_set_text (CLUTTER_TEXT (help_label), Press 'q' to quit);

  clutter_timeline_start (timeline);

  data = test_thread_data_new ();
  data-stage = g_object_ref (stage);
  data-label = g_object_ref (count_label);
  data-progress = g_object_ref (progress_rect);
  data-timeline = g_object_ref (timeline);
  g_thread_create (test_thread_func, data, FALSE, NULL);
  return TRUE;

case CLUTTER_q:
  clutter_main_quit ();
  return TRUE;


Re: [clutter] problem with threads and clutter-texture from file: Failed to create COGL texture

2009-12-02 Thread Emmanuele Bassi
On Wed, 2009-12-02 at 13:52 +, Emmanuele Bassi wrote:

oh, and by the way: if your only goal is to load a texture from file
asynchronously, please - *please* - do what Bastian already suggested,
and use the :load-async property of ClutterTexture. it will
transparently use threads to load the texture data from a provided file
name.

ciao,
 Emmanuele.

-- 
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com



Re: [clutter] problem with threads and clutter-texture from file: Failed to create COGL texture

2009-12-02 Thread Aapo Rantalainen
Hi, thanks, I got it working.

In test-threads.c there was this row:
clutter_threads_add_idle_full (G_PRIORITY_DEFAULT + 30,
 update_label_idle,
 update, NULL);

So I though it is safe to put my clutter_* code same place. (So is
this clutter_threads_add_idle_full also in clutter API or not?)
Now I put my code under update_label_idle, which have clutter_actor_*
calls, so this might be safe place?


I have lots of code using ClutterScript and json files. I realized
that my target platform is too slow to load actors when needed, but it
has lots of memory.  I would like to use existing code, not to rewrite
them using 'load-async'.

-Aapo Rantalainen
-- 
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com



Re: [clutter] problem with threads and clutter-texture from file: Failed to create COGL texture

2009-12-02 Thread Emmanuele Bassi
On Wed, 2009-12-02 at 16:54 +0200, Aapo Rantalainen wrote:
 Hi, thanks, I got it working.
 
 In test-threads.c there was this row:
 clutter_threads_add_idle_full (G_PRIORITY_DEFAULT + 30,
  update_label_idle,
  update, NULL);
 
 So I though it is safe to put my clutter_* code same place. (So is
 this clutter_threads_add_idle_full also in clutter API or not?)

no; the API subset that's clearly thread-related and that it safe
(unless obviously not - like clutter_threads_init() and
clutter_threads_set_lock_functions() - but these are clearly marked as
such) to be called from another thread is set in the clutter_threads_*
sub-namespace. we cannot put it in another namespace altogether - this
is still Clutter API.

 Now I put my code under update_label_idle, which have clutter_actor_*
 calls, so this might be safe place?

yes; idle and timeout callbacks will be executed from within the same
thread that is spinning the main loop.

 I have lots of code using ClutterScript and json files. I realized
 that my target platform is too slow to load actors when needed, but it
 has lots of memory.  I would like to use existing code, not to rewrite
 them using 'load-async'.

load-async is a GObject property, and can be defined using
ClutterScript:

  {
type : ClutterTexture,
load-async : true,
filename : /path/to/filename,
  }

will load the file asynchronously - as long as you use Clutter from
master, which guarantees the ordering of object members; otherwise just
set load-async to true and call clutter_texture_set_from_filename()
explicitly.

ciao,
 Emmanuele.

-- 
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com



RE: [clutter] problem with threads and clutter-texture from file: Failed to create COGL texture

2009-12-02 Thread Emmanuele Bassi
Just curious, what is the point of the threads_enter  threads_leave
API if everything breaks outside of the main thread? Isn't even
providing them asking for misunderstandings like this?

You can replace the locking primitives Clutter uses through

  clutter_threads_set_lock_functions()

And use, for instance, a re-entrant lock.

Mostly, enter/leave are meant for language bindings and integration
libraries, to enslave the Clutter lock to another locking system; The
Python bindings, for instance, cannot use the clutter_threads_add_* API and
must reimplement it in order to take the interpreter lock as well. Without
clutter_threads_enter() and clutter_threads_leave() in the public API this
would not be possible.

Also, on Linux it's possible to use them (as I said) to mark a critical
section; if you don't care about portability then it's something you can use
- though it's discouraged and an unfortunate accident involving a bucket of
puppies and a belt sander might happen if you don't follow the established
worker-thread-sends-results-in-idle pattern.

Ciao,
 Emmanuele.

-- 
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com



[clutter] Clutter for a multi-head, full-screen application

2009-12-02 Thread Damiano Verzulli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

I'm currently evaluating the possibility to build an application using
clutter (better if via perl of python bindings) and I'm wondering if
clutter could be a suitable approach.

My goal is to have one application running on a single linux-box with a
dual-head graphic adapter. The application:
a - should run full-screen in both the two monitors;
b - should display several images (.png files) getting them from the
underlying file-system and applying some nice-transitions [3D effects
applyied to 2D objects] between them (rotate, zoom-in, zoom-out, scroll, etc.);
c - should display some nice-formatted text as labels for images above.

(in other words: it's an applications to be run in a
network-monitoring-room, to display network usage and other near-real-time
graphical data got from the monitoring system, on two large screens [52 -
1920x1080], with mostly no user-interaction)

Is clutter ok for such an application?

More in detail:

1 - is clutter capable to run full-screen on _both_ monitors? (note: I
can surely use an NVIDIA card and configure Xorg to use TwinView; I also
can configure Xorg with separate screens and I can even use two different
Xsessions -- no constraint regarding Xorg configuration);

2 - As I'd prefer to use clutter-perl (1.0, when I'll be to succesfully
build it but that's another story), will I miss something in respect to
the main C-language version?

3 - Do someone have some URLs or other documentation that I should check
before starting coding (in addition to the one available on the clutter web
site)?

Thanks in advance,
Damiano

- --
Damiano Verzulli
e-mail: dami...@verzulli.it
- ---
possible?ok:while(!possible){open_mindedness++}
- ---
...I realized that free software would not generate the kind of
income that was needed. Maybe in USA or Europe, you may be able
to get a well paying job as a free software developer, but not
here [in Africa]... -- Guido Sohne - 1973-2008
   http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksW3RwACgkQcwT9fsMT4SyAEQCdF6sj4l1nU927V3fYghkAmIg2
RjMAn2SJknf1Dfw+8xRCc2YWRDr3BUzx
=WYFb
-END PGP SIGNATURE-
-- 
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com