[Jde-dev] redimiento temporal en 5.0
David Lobato
dav.lobato en gmail.com
Vie Feb 19 15:13:53 CET 2010
Buenos días (states time),
Entiendo que lo que has hecho es quitar la herencia de Observer en la clase
View, de modo que ya no recibe las notificaciones del modelo, y llamas al
update de la clase desde el programa principal al ritmo que necesitas,
¿no? Es una solución, aunque se le quita toda la gracia el asunto...
¿Sigues teniendo una sola hebra para todo?
Otra solución que mantiene las ventajas de este patrón de diseño podría ser
indicar a la clase view el ritmo de actualización, y que al ejecutar el
update tras un notify, este sólo ejecute el código de repintado según el
ritmo indicado.
Si pasamos a 2 hebras (modelo,controlador | vista), además de lo anterior,
podemos hacer que el notify avise a la hebra de la vista para hacer su
trabajo. En este caso habría que controlar el acceso concurrente al modelo
(monitor?).
Independientemente de esto, tenemos que pensar que estas gui's son un mero
interfaz de depuración. Una vez nuestro componente está depurado, la manera
de comunicarse con el será a través de su interfaz ICE que ya soluciona
todos estos detalles.
David.
2010/2/19 Sara Marugan <s.marugan en alumnos.urjc.es>
> Buenas,
>
> he llegado a una solución intermedia para la implementación de mi
> componente eldercare. He mantenido el modelo y su controlador pero he
> reemplazado la clase Observer por una clase viewer para el manejo del GUI,
> así se elimina la dependencia de notifyObservers().
>
> La clase viewer se comunica con el modelo a través del controlador, pero
> ahora es el programa principal y no el controlador el que se encarga de
> indicar a la clase viewer cuando repintar el GUI.
>
> De esta forma mi componente itera a unas 24 ips, tanto si sólo visualizo
> como si además filtro las imágenes por movimiento.
>
>
>
>
> JoseMaria wrote:
>
>> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20100219/fd58f99c/attachment-0001.htm
More information about the Jde-developers
mailing list