Hola amigos,

ando a vueltas con la clase Paint. He preparado un ejemplo que adjunto donde se pueden ver algunos de los problemas que he encontrado. He puesto la propiedad del drawing area Cached a False, de modo que es dentro del evento Draw de este drawing area donde se lanza implícita y automáticamente el Paint.Begin...Paint.End, y dentro de ese evento donde se llama a una función que pinta las líneas.

Para empezar diré que esta clase es lenta... Si se quieren dibujar unos cientos de líneas y empezamos a hacer zooms rápidamente esto que digo empieza a ser evidente. En segundo lugar, si nos acercamos suficientemente con el zoom (sí, ahí tenéis un ejemplo práctico del zoom dinámico que en una ocasión contaba Fundamento teórico del zoom dinámico) hay algunas líneas que "desaparecen" misteriosamente (¿bug?), y haciendo un poco más de zoom vuelven a aparecer. En tercer lugar, las líneas de trazos o de puntos tardan más en dibujarse que las continuas. En las líneas de puntos hay algunos de esos puntos que también desaparecen.

Un saludo

Alaplancha:

Estoy empezando a verlo. Primera impresión.

Si la ventana ocupa toda la pantalla, las lineas del dibujo, ¿ No deberían ocupar toda esa ventana de dibujo ?.
Es que parece dibujar siempre en el mismo recuadro, en vez de ampliar a una zona mayor de dibujo.

Sigo viéndolo.

Pues yo no lo veo tan lento. ¿ Seguro que con 100 lineas es lento ?. No lo veo.
A ver si es cosa del ordenador que usas.  
En mi caso es un Core Duo E8400 3Ghz. Ya tiene tiempo.
Gráfica Asus GTX260..un monstruo que no aprovecho. Y que resulta una burrada de tamaño de tarjeta.    

Esto, el zoom una maravilla.No llegaste nunca a llevar el tutorial a  código.
Se agradece, tenia formula de todos los colores. En cambio en el ejemplo,no parece que haya
tanta formula.

Ah, no he visto lineas que desaparezcan. Esta bien.

Este es el único error que he visto al salir de la aplicación:

gbx3: warning: 1 allocation(s) non freed.

(Aja,..no uses Quit. usa Me.Close)

Cambie para probar de gb.gui a gb.qt4, las lineas no aparecen hasta usar un optionbutton.
Danos un poco de información sobre que gambas usas y el equipo. (Que gustandote el cad, seguro que tienes un "monstuo" )

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Hola Shell,

¡muchas gracias por tu respuesta!

Las líneas de prueba no ocupan todo el drawing area, porque sorteo sus coordenadas sólo entre 0 y 10, y con la escala que pongo al principio quedan como dentro de un cuadrado imaginario. Pero después al hacer zoom nos podemos acercar y desbordan los límites del drawing area. Bueno, era sólo por pintar un número de líneas muy grande, así que hice ese sorteo de x e y entre 0 y 10 nada más.

En efecto, tienes razón en que cambiando de componente, en vez de gb.gui pongo gb.qt4, se puede observar lo siguiente:
- Hay que elegir uno de los tres RadioButton, ya que si no no se pinta nada.
- El defecto de líneas que desaparecen, o líneas horizontales que aparecían misteriosamente ya no se produce. Eso es una gran mejoría.
- Las líneas continuas parece que se pintan más rápidamente.
- En cambio las líneas de trazos o de puntos se ralentizan mucho más con el componente gb.qt4 que con el gb.gui (por ejemplo, con 4000 líneas, entre que giras una posición la rueda y se vuelve a pintar, o si cambias de lineas continuas a trazos, pasan unos segundillos eteeeeernos).

Gracias por lo de remplazar close en lugar de quit, no sabía por qué daba ese warning.

En cuanto a mi equipo, no es una gran maravilla. Es un portátil Hp con:
- procesador Intel® Core™2 Duo CPU T6570 @ 2.10GHz × 2
- 3'8 Gb de memoria
- Ubuntu Versión 12.04 (precise) de 32-bit
- Núcleo Linux 3.2.0-41-generic-pae
- GNOME 3.4.2
- gambas 3.4.1

Me gustan los programas CAD, que aparte de para dibujar planos pueden servir para muchas cosas más, y el zoom éste lo pensé para ese tipo de aplicaciones. Hay que tener en cuenta que en un programa CAD puede haber varios miles de entidades de dibujo, y el zoom se utiliza constantemente, por lo que la velocidad de representación es algo muy importante, y un segundo en cada paso de zoom con la rueda se hace eterno y poco funcional.

El fundamento teórico del zoom es un poco pesadito y lioso, con vectores pa arriba vectores pa abajo, que parece que atacan los indios con tantas flechitas, pero después las fórmulas finales son muy sencillas de aplicar.

Un saludo.

Hola Pablo.

Lo he bajado aquí en el trabajo para ver como va y tener tiempo para estudiar un poco mejor el código, en momentos
de tranquilidad, claro.

Este equipo es mas lento.

Bueno, un portatil no es un ordenador pensado para "caña". Hace unos años, me comentaba un comercial del Corte Ingles,
las burradas de maquinas que se hacían para portátiles, que se comían la batería con patatas.

No se exactamente con tu pc el rendimiento que puede dar para estas cosas.Ni idea, la verdad.
4000 lineas ya es otro color.

Me alegro de encontrar a alguien mas en la comunidad que le gusta el dibujo con Gambas.
Vemos poco, esto. Tampoco es que sea fácil. Julio también ha hecho sus ejemplos.

Lo que si veo.A pesar de los estudios que podamos tener, cosas como pasarlo a una aplicación te frena.
Requiere su tiempo.Desde luego no sale a la primera y hay que volver a insistir. Tenemos pequeños tropiezos
de optimizar el código.Conocer mejor las instrucciones del lenguaje, mas estudiar.

Por otra parte en dibujos que requieran una velocidad.No nos va quedar mas remedio que estudiar un poco
de OpenGL, si queremos que vaya fluido.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Hola Shell,

mi equipo no es una maravilla   . Afortunadamente siempre hay personas dentro de la Comunidad, como es tu caso, que se animan a probar los códigos de otros para testarlos en otros equipos, y proponer sugerencias, gracias a todo ello vamos mejorando y aprendiendo nuevas cosas. En mi caso no tengo muchos conocimientos de informática, pero la parte geométrica, pensar algoritmos, refinarlos, me gusta y me defiendo como puedo. Me alegro de que estéis otros en el foro a los que también os guste este tipo de aplicaciones. En cuanto a lo del OpenGL, me da un tanto de miedo, si apenas consigo hacerme con la clase Paint, ya ves. Pero puede que ponerse a estudiarla es algo inevitable si al final lo que se busca una mayor velocidad gráfica.

Un saludo.

Hola

Probado con un procesador I7 a 3.4GHz, aquí la gráfica no importa porque no se hace uso de la GPU. Todo el trabajo recae en la CPU y os aseguro que uno de los procesadores de los 8 que lleva se pone al 100%.

Como bien decís, al usar gb.qt4 va más rápido que con gtk (o gb.gui) razonablemente rápido con 10000 líneas en mis pruebas. Desde luego, gambas no es la mejor opción para CAD, porque las clases de dibujo efectivamente son lentas.

Otra cosa es opengl, aunque tampoco sé si será la forma de hacer programas tipo CAD...

Por cierto, hablando de los gustos por el dibujo, cosa a la que me apunto; ¿alguien se ha planteado hacer un programa de reconocimento de matriculas que no haga uso externo de ocr? Y si no queda más remedio que usar ocr (gocr) para analizar los caracteres, ¿cómo detectar las placas, aislarlas, ampliarlas y normalizarlas para facilitar el trabajo del ocr?

Estuve hace poco haciendo pruebas, vamos, jugando con gocr y me pareció interesante, hasta el punto de plantearnos hacer un programa o la base para desarrollar este tipo de programas en gambas.

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Es una pena que por ahora en cuestión de este tema  en gambas que "aun" no se use la GPU.
Claro que hay hace ya tiempo en su día, existían las tarjetas que hacían cálculos de física,
como AGEIA, que luego la acabo comprando NVIDIA. Incorporándola a Physx.

Si para el trazado se pudiera ganar en velocidad.
Ejemplo con texturas.


Link


Ejemplo con materiales.

Link


Siempre creí que de alguna de estas posibilidades se llevarían al CAD.

[Ocr]

Aun no he probado nada de ocr en Linux, tendría que ver primero el tema.  

Cuando en su día hice pruebas de ocr bajo Windows no me convenció, se comía letras o las confundía.
Cuestión de ver como va en Linux.

La idea de convertir un grupo de caracteres a una gran cantidad, la veo mas efectiva.
Aunque puede haber artículos,textos.Claro que con un scanner y crear un pdf.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Hola Jesús,

gracias por probar el ejemplo. Algún día me animaré con el Opengl, aunque no sabemos tampoco cuánto se ganará en velocidad. Imagino que para programas gráficos hay que pasar a programación de otro nivel. Y en mi caso me queda mucho por aprender antes que eso.

En cuanto al ocr no lo he investigado nunca. Es un campo también muy interesante, y no sólo el reconocimiento de caracteres, sino el reconocimiento de imágenes en general, entrando ya en conceptos de percepción y casi inteligencia artificial.

Saludos

Sobre OCR, yo he probado ocrfeeder, que viene en los repositorios. No funciona nada mal. Tan sólo que por defecto sólo viene en Inglés y hay que toquetearle a las configuraciones, no recuerdo muy bien qué -algo facilito-. Hice algunas pruebas y en imágenes y pdf de no demasiadas páginas, es aceptable. Tanto más fallos cuanto más baja la calidad del escaneado, pero aceptable, ya te digo. Está basado en la librería Tesseract (cito de memoria).

Saludos.