[Jde-dev] redimiento temporal en 5.0
JoseMaria
jmplaza en gsyc.es
Vie Feb 19 10:18:12 CET 2010
Otra cosilla más:
esta separación entre código de visualización y código de funcionamiento
es buena para la mayoría de las aplicaciones que controlan algo o
perciben algo, típicamente basadas en iteraciones periódicas. Separarlos
en hebras distintas es buena idea.
También hay componentes que pueden organizarse "orientados a eventos",
típico de las aplicaciones gráficas (con GTK, QT, xforms...). Por
ejemplo opencvdemo (un componente de demostración de opencv, sus
filtros, transformadas y operaciones sobre imágenes) sólo hace el
procesamiento para enseñárselo al humano. Puede organizarse como un
conjunto de respuestas a diferentes eventos: que llegue una nueva
imagen, que el usuario pique en un botón para activar tal o cual filtro,
etc.
Saludos,
JoseMaria
On Thu, 2010-02-18 at 16:00 -0500, David Lobato wrote:
> Lo primero aclarar que las clases Observer y Subject las he escrito yo
> y no tienen nada que ver con Ice. Por lo que son totalmente
> reimplementables/reemplazables. Son muy simples y no hay nada de
> hebras relacionado con ellas.
>
>
> Así que como deduces, hay una sola hebra haciendo todo el trabajo. Lo
> ideal sería que la gui tuviese la suya y pintase desacoplada del
> resto. Pero por pereza/desconocimiento de gtk lo dejé así en mi
> aplicación, que teniendo una gui muy sencilla no requería mas.
>
>
> Como dice José María hay que encontrar la manera de separar ambas
> partes. Así que necesitamos que las notificaciones que emite el Modelo
> sean asincronas, cosa que ahora no ocurre, o directamente pasar a
> repintar a intervalos fijos como se venía haciendo. La idea de las
> notificaciones es mas elegante pero algo mas compleja de implementar
> (aunque nos podemos apoyar en cosas ya hechas como SigC++/SigCX;
> señales al estilo gtk).
>
>
>
> 2010/2/18 Sara Marugan <s.marugan en alumnos.urjc.es>
> Bueno, investigando un poco más con grep, he visto que
> notifyObservers() acaba llamando a update() de la clase View
> del modelo MVC, que realiza lo equivalente a Viewer::display()
> de la otra opción de implementación.
>
> Ahora tengo la duda de si un objeto Observer implica crear una
> hebra de ejecución diferente sólo para la visualización. Si
> no, tanto la lógica de la aplicación como las instrucciones de
> visualización se ejecutan en el mismo proceso, obligando a ir
> al ritmo de la actualización del GUI.
>
> He medido las iteraciones por segundo en el método setimages()
> del modelo y efectivamente son 5 ips, las mismas que da la
> clase View en su método update(). Por tanto, todo indica que
> sólo hay un proceso para todo.
>
>
>
>
> JoseMaria wrote:
> Hola,
>
> La separación entre visualización y funcionamiento es
> algo deseable para
> el software de robots. Muchas veces se quiere
> visualizar para depurar y
> no es necesario que el robot muestre nada cuando hace
> tal o cual tarea,
> simplemente que la haga.
>
> Por eso en la 4.3 estaban separados en ejecución el
> código de
> funcionamiento (run,stop,iteration) del de
> visualización (show,hide).
> Estaban escritos típicamente en el mismo fichero, pero
> los ejecutan
> hebras diferentes: El código de funcionamiento lo
> ejecuta la hebra del
> esquema (a su ritmo genuino) y el código de
> visualización la hebra de
> graphics_gtk o graphics_xforms (que también lleva su
> propio ritmo, unos
> 12ips).
>
> En 5.0 ahora tenemos más libertad para desacoplar aún
> más el código de
> una cosa y el de la otra. El patrón
> Model-View-Controller es una buena
> opción para ello, pero hay que tener cuidado
> programando para evitar las
> dependencias excesivas de unos con otros. Por ejemplo
> la visualización
> debería mostrar las iteraciones por segundo a las que
> funciona el código
> de funcionamiento, no las de visualización (que puede
> estar bien, pero
> no es tan relevante). También es tolerable cierto
> desfase (pequeño)
> entre lo que se visualiza y los datos actuales de
> funcionamiento.
>
> Ánimo,
>
> JoseMaria
>
>
> Independientemente, lo que andaba buscando es
> una manera de desacoplar
> al máximo el código de la visualización.
> Actualmente, en los esquemas
> de la 4.3, todo se entremezcla, resultando
> complicado distinguir entre
> código de la aplicación y código de la
> visualización. Así que se me
> ocurrió que podría aplicar algún patrón de los
> que se usan en
> aplicaciones con visualización. MVC y sus
> variantes son patrones de
> este tipo.
>
>
>
> En este patrón se separan los datos (modelo)
> de la interfaz gráfica
> (vista), utilizando un intermediario
> (controlador). El controlador se
> encarga de actualizar el modelo con los
> cambios que provengan de la
> vista (pulsar un boton, caja de texto,...) o
> del exterior (en nuestro
> cosa de la red). A su vez, el modelo envía una
> notificación de que sus
> datos han cambiado, que es recibida por todas
> las vistas suscritas al
> modelo (usamos patrón Observer para esto) y
> que se encargan de releer
> el modelo y actualizarse (repintar el gui).
>
>
> En principio suena bien. Pero pensando en el
> caso concreto que Sara
> está implementando, creo que sucede lo
> siguiente:
>
>
> Supongo que el modelo de Sara no es mas que un
> almacen de 4 imagenes
> (cada una de las recibidas de cada cámará) que
> el el controlador
> actualiza de 1 en 1 usando un método tipo
> setImage1, setImage2,...
> Dichos métodos, a su vez, envían una
> notificación de cambio a las
> vistas. Las vistas, que no son capaces de ver
> que ha cambiado
> concretamente repintan todo. Es decir, que
> estamos actualizando la gui
> por cada imagen recibida y de ahí que el
> rendimiento haya caido tan
> notablemente.
>
>
> Se me ocurre que podemos añadir mas
> información a la notificación que
> genera el modelo, para indicar que es lo que
> ha cambiado, de modo que
> la vista sólo pinte aquello que ha cambiado.
>
>
> ¿Mas ideas? ¿Otros patrones que podamos
> aplicar a nuestros componentes
> con gui?
>
>
> David.
>
>
>
>
>
>
>
>
> 2010/2/18 Juan Antonio Breña Moral
> <bren en juanantonio.info>
> Hola Sara,
> No me he puesto a trabajar con el MVC
> de JDRobot 5.0 pero
> tiene pinta de que en muchas
> iteraciones de los componentes,
> los datos pasan por el controller y
> otras areas en teoria, te
> lo digo con desconocimiento de como lo
> haces.
> Yo hasta donde llego MVC es un
> patron de diseño que se emplea
> en aplicaciones de gestion, vease
> Structs2 [1] no tenia
> constancia que en Robotica tambien era
> valido separar la capa
> de datos del control. Quizas debido a
> eso si la vista es el
> GUI y el Model es el Sensor, cada
> iteracion del Sensor pasa
> siempre por el controller y este hace
> una serie de tareas y
> quizas por eso repercuta en el
> rendimiento.
> ¿La forma tradicional no es
> valida?
> ¿Si un componente gestiona un sensor o
> grupo y se comunica con
> ICE con otra area?
> Un abrazo
> [1] http://struts.apache.org/
> Sara Marugan escribió:
> > Claro, al utilizar el MVC tiene que
> introducir algo de latencia, pero >
> tanta me parece excesiva.
> > > > Juan Antonio Breña
> Moral wrote:
> > > > Puede que sea la propia
> arquitectura MVC.
> > > ¿Es posible?
> > > > > Sara Marugan escribió:
> > > > > > Hola,
> > > > > > > quería comentaros
> una cosa y es que he hecho dos componentes
> > > > diferentes que reciben imágenes de
> 4 cámaras a la vez y las muestran. > >
> > El primero está basado en varcolorviewgtkmm,
> que no utiliza el modelo > > > MCV, y
> el segundo en motiondetection, que sí lo
> utiliza.
> > > > > > > Mi sorpresa es que
> mientras que el primero ejecuta a 30 ips, el
> > > > segundo a 5 ips. ¿A qué puede
> deberse esto? en el segundo intervienen
> > > > más clases pero me extraña que
> introduzcan tanta latencia. ¿Es > > >
> ajustable el ritmo de ejecución?
> > > > > > > gracias de antemano,
> > > > > > > Sara
> > > >
> _______________________________________________
> > > > Jde-developers mailing list
> > > > Jde-developers en gsyc.es
> > > >
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> > > > > > > > > >
> >
> _______________________________________________
> > Jde-developers mailing list
> > Jde-developers en gsyc.es
> >
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> > >
> -- Juan Antonio Breña
> Moral
> www.juanantonio.info
> www.roboticaenlaescuela.es
> www.robotica-urjc.es
> Este mensaje (incluyendo los
> archivos adjuntos) es confidencial y
> reservado. Si Vd. lo ha recibido por error,
> por favor notifíquelo al emisor del mismo vía
> e-mail y borre el mensaje de su sistema.
> Cualquier uso no autorizado o divulgaciín de
> su contenido, ya sea en todo o en parte, está
> totalmente prohibido. Tenga en cuenta que los
> e-mails son susceptibles de ser modificados.El
> remitente no se hará responsable de la
> incorrecta o incompleta transmisión de la
> información contenida en esta comunicación, ni
> por ningún retraso en la recepción o daño a
> sus sistemas. el remitente no garantiza que
> esta comunicación se ha realizado en su
> integridad ni que la misma no contiene virus,
> intercepciones o interferencias. Este e-mail
> ha sido escaneado mediante la utilización de
> Antivirus.
> El tratamiento de los datos de
> carácter personal, así como el envío de
> boletines o comunicaciones realizadas por
> medios electrónicos, son conforme a la Ley
> Orgánica 15/1999, de 13 de diciembre, de
> Protección de Datos de Carácter Personal
> (B.O.E. de 14 de diciembre de 1999) y a la Ley
> 34/2002, de 11 de julio, de Servicios de la
> Sociedad de Información y de Comercio
> Electrónico (B.O.E. de 12 de julio de 2002).
> El tratamiento desautorizado de datos de
> caracter personal puede suponer una infracción
> de la Ley Orgánica 15/1999, de 13 de
> diciembre, de Protección de Datos de carácter
> personal. Si usted no es el destinatario que
> figura arriba, o la persona responsable de su
> entrega al mismo, deberá de abstenerse de
> examinar o utilizar su contenido, realizar
> copias o entregarlo a persona distinta. Para
> obtener información sobre la política de
> privacidad o para el ejercicio de
> derechos de acceso, rectificación,
> cancelación y oposición, puede dirigirse a
> este correo electrónico, indicando en el
> asunto "Protección de Datos".
> This message (including any
> attachments) is confidential and may be
> privileged. If you have received it by
> mistake, please notify the sender by return
> e-mail and delete this message from your
> system. Any unauthorized use or dissemination
> of this message in whole or in part is
> strictly prohibited. Please note that e-mails
> are susceptible to change. The sender shall
> not be liable for the improper or incomplete
> transmission of the information contained in
> this communication, nor for any delay in its
> receipt or damage to your system. The sender
> does not guarantee that the integrity of this
> communication has been maintained or that this
> communication is free from viruses,
> interceptions, or interference. This email has
> been scanned using Antivirus
>
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
>
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>
>
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>
>
>
>
>
>
>
>
--
http://gsyc.es/jmplaza
Universidad Rey Juan Carlos
More information about the Jde-developers
mailing list