[Jde-dev] redimiento temporal en 5.0
David Lobato
dav.lobato en gmail.com
Lun Feb 22 13:50:47 CET 2010
Hola,
Pues sue�a complicado el asunto.
A priori parece obvio que si ponemos una hebra por cada c�mara y se piden
las im�genes en paralelo podr�amos bajar los tiempos. Aunque habr� que ver
como gestiona esto ICE. Aun estamos en el mismo proceso, y usando el mismo
comunicador para todo. Adem�s habr� que a�adir mecanismos de control de
concurrencia, ahora las imagenes no son punteros y probablemente si no lo
hacemos habr� condiciones de carrera casi seguro.
Quiz� sea momento de usar los mecanismos de suscripci�n que tiene ICE, de
modo que no pidamos im�genes, si no que nos suscribamos a la c�mara y estas
lleguen cuando est�n listas. Aun no he probado este mecanismo, aunque en
Orca tienen varios ejemplos e implementaciones.
2010/2/22 Sara Marugan <s.marugan en alumnos.urjc.es>
> Buenas,
>
> escribo para comentaros las novedades que he visto en cuanto al tema del
> rendimiento temporal. Me he dado cuenta de que no hab�a diferencia entre el
> componente dise�ado con MVC y el componente que no lo estaba, hab�a un bug
> que me hac�a creer que iba m�s r�pido el segundo.
>
> Por lo que he visto haciendo pruebas, el cuello de botella no est� en
> pintar el GUI, sino en recoger las im�genes de entrada. En obtener una
> imagen del proxy tarda 70ms, lo que multiplicado por 4 en mi caso provoca
> que mi componente itere a unos 4 fps sin a�adir los algoritmos.
>
> Como primera soluci�n se me ocurre que el componente genere una hebra por
> cada c�mara y que se encarguen de obtener las im�genes y dejarlas en memoria
> para que est�n r�pidamente accesibles desde el proceso principal.
> Qu� otras soluciones veis?
>
> Un saludo,
>
> Sara
>
>
>
>
>
> David Lobato wrote:
>
>> 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 <mailto:
>> 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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto:Jde-developers en gsyc.es>
>>
>> >
>>
>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>> > >
>> -- Juan Antonio
>> Bre�a
>> Moral
>> www.juanantonio.info
>> <http://www.juanantonio.info>
>> www.roboticaenlaescuela.es
>> <http://www.roboticaenlaescuela.es>
>> www.robotica-urjc.es
>> <http://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
>> <mailto: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
>> <mailto: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/20100222/2e8b06fd/attachment-0001.htm
More information about the Jde-developers
mailing list