| *** tpb has joined #timvideos | 00:00 | |
| *** synaption[m] has quit IRC | 00:19 | |
| *** synaption[m] has joined #timvideos | 00:19 | |
| diamondman | I have found myself trying to draw text/shapes to non standard displays with non square pixels such as https://github.com/diamondman/att26a or yarn in a scarf. If I just use standard rasterization, text looks stretched on these bizarre mediums. I know this is not explicitly video related, but since video deals with these types of transformations, I was hoping someone may have a pointer on where I should start. I would | 00:46 |
|---|---|---|
| diamondman | greatly appreciate any suggestions. | 00:46 |
| tpb | Title: GitHub - diamondman/att26a: Documentation and driver for AT 26A Direct Extension Selector Console. (at github.com) | 00:46 |
| CarlFK | diamondman: I get what you are asking.. um.... | 01:29 |
| CarlFK | 2 answers that are non answers | 01:34 |
| CarlFK | 1. #xorg - I'm sure there are video drivers that deal with this | 01:34 |
| CarlFK | 2. don't worry about it. have your layer provide a way to read switches and turn lights on. let the next layer up deal with mapping the hardware to virtual stuff | 01:36 |
| CarlFK | I doubt #1 is worth the effort. I think #2 will be fine | 01:37 |
| *** cr1901_modern1 has joined #timvideos | 02:13 | |
| *** cr1901_modern has quit IRC | 02:14 | |
| *** cr1901_modern1 has quit IRC | 02:22 | |
| *** cr1901_modern has joined #timvideos | 02:22 | |
| diamondman | CarlFK: I want to ask details on that. Should I reply here (since it is a little off topic) or bring it to a PM? | 02:28 |
| CarlFK | here is fine | 02:28 |
| diamondman | CarlFK: If someone wants to display text on a display that has rectangular pixels, how is that done? Are the square pixels blended together in a way to make a similar image in the rectangular pixels? | 02:41 |
| diamondman | display text -> display anything | 02:41 |
| CarlFK | I think you have to back up and ask: how is anything displayed on anything | 02:42 |
| CarlFK | horizontal and vertical lines are easy | 02:42 |
| CarlFK | diagonal lines and arcs and curves and shading = math | 02:43 |
| diamondman | Lol. Well I know how the hardware buffers would send pixel data, etc. if everything is square, then you just copy pixels. Rasterization of shapes move over the pixel grid and the a color is set based on how much that volume covers of that pixel.... | 02:44 |
| diamondman | But if you draw a curve on a grid, and then convert that grid of squares into a grid of rectangles, you gotta do a lot of lossy conversions for each pixel... | 02:44 |
| diamondman | That seems too wasteful for there not to be a way to draw things directly to rectangle pixels | 02:45 |
| CarlFK | curve on a grid takes math | 02:45 |
| diamondman | yep math :) | 02:45 |
| CarlFK | that's where you can deal with the grid not being 1x1 | 02:45 |
| CarlFK | I think I can make up an example... | 02:48 |
| diamondman | So if a system draws only to a grid of squares, then the options to get that on a grid of rectangles are 1) Modify the system to support different pixel shapes; 2) write/find something to convert between the grid of squares to the grid of rectangles using a lossy conversion | 02:48 |
| CarlFK | #2 is extra work | 02:49 |
| diamondman | extra work for me or the machine? | 02:49 |
| CarlFK | everyone | 02:49 |
| diamondman | fair | 02:49 |
| diamondman | If a timvideo setup is going to display on a tv with rectangular pixels, and some vector stuff needs to be added to the image, is it first rendered to a square pixel grid, and then converted by something to be able to show up on the tv? | 02:51 |
| diamondman | (trying to make it relevant to the channel :) ) | 02:51 |
| CarlFK | we use drivers that handle the translation between a vector and the display | 02:52 |
| CarlFK | how about drawing a circle on the screen that is 1" diameter, centered on the display | 02:53 |
| CarlFK | 1" is not at all 1 pixel | 02:53 |
| CarlFK | centered is not .5 | 02:53 |
| CarlFK | you need to know something about the display | 02:53 |
| CarlFK | sin() and cos() return a number from -1 to 1 | 02:55 |
| CarlFK | to get the x, you multiply it by something that gets you the X you want | 02:56 |
| CarlFK | to get the X, you multiply it by something that gets you the Y you want | 02:56 |
| CarlFK | er, Y ... Y | 02:56 |
| CarlFK | if the grid is square, the something is the same. | 02:56 |
| CarlFK | if the distance between 2 Y's is more than 2Xs, then you multiply by less to get the same distance, and a round circle, not an egg | 02:58 |
| CarlFK | that's where the reality of the display can (should?) be applied | 02:59 |
| diamondman | yep. makes sense that you should apply the transformation when you are first drawing into the pixel buffer | 03:01 |
| diamondman | Just redraw it if you are using different pixel shapes. | 03:02 |
| diamondman | If you are not writing the code that does that math part, is the only option to make a lossy converter from one grid shape to the other? | 03:02 |
| CarlFK | I think so | 03:04 |
| CarlFK | but that kinda implies that the people doing the math are expecting 1x1 squares | 03:04 |
| CarlFK | er, yeah, I take back the think so... | 03:05 |
| CarlFK | the people doing the math should ask the lower level what shape the grid is | 03:05 |
| CarlFK | 3:4 TVs, both American NTSC and the rest of the world's PAL, both had rectangular pixels | 03:06 |
| CarlFK | something about the reality of making the beam turn on/off fast enough | 03:07 |
| diamondman | older hardware than when computer monitors started popping up | 03:21 |
| diamondman | I was asking if there is some standard layer for specifying that, or doing the lossy conversion | 03:23 |
| diamondman | sounds like no? | 03:23 |
| diamondman | I was asking = I think what I meant to ask | 03:23 |
| diamondman | Thanks for the input :) | 03:26 |
| CarlFK | I think what you are asking is what video drivers are all about - but I'm kinda guessing in all accounts | 03:34 |
| CarlFK | like I think the GPU is what does the math when you want things blazing fast | 03:35 |
| CarlFK | and then the app needs to know how to tell the gpu to draw a shape | 03:35 |
| *** rohitksingh has joined #timvideos | 03:48 | |
| *** cothan has joined #timvideos | 03:55 | |
| *** rohitksingh has quit IRC | 04:04 | |
| cothan | Hi, I read about the project from Gsoc page, as a phd student, my research interest is hardware-software codesign, like SdSoc, MPSoC in Xilinx, at my work, I implement hardware design in C-based High Level Synthesis (instead of vhdl, but the coding is hardware style, not to make software synthesizable in hardware), my initial idea for gsoc this year is to port some major software function to hardware as accelerator. is it sound goo | 04:04 |
| *** cothan has quit IRC | 04:12 | |
| *** rohitksingh_work has joined #timvideos | 04:19 | |
| *** futarisIRCcloud has quit IRC | 06:14 | |
| *** m4ssi has joined #timvideos | 07:57 | |
| *** seb_ has quit IRC | 08:01 | |
| *** andi-m has quit IRC | 09:25 | |
| *** andi-m has joined #timvideos | 09:27 | |
| *** futarisIRCcloud has joined #timvideos | 10:49 | |
| *** rohitksingh_work has quit IRC | 13:01 | |
| cr1901_modern | There should be a "wait up to 24 hours for a reply" blurb in the topic... | 13:38 |
| *** rohitksingh has joined #timvideos | 13:51 | |
| *** swalladge has quit IRC | 14:07 | |
| *** Kripton has quit IRC | 14:40 | |
| *** Kripton has joined #timvideos | 14:43 | |
| *** rohitksingh has quit IRC | 15:07 | |
| *** futarisIRCcloud has quit IRC | 15:19 | |
| *** rohitksingh has joined #timvideos | 15:36 | |
| *** rohitksingh has quit IRC | 16:22 | |
| *** rohitksingh has joined #timvideos | 16:24 | |
| *** rohitksingh has quit IRC | 16:56 | |
| *** swalladge has joined #timvideos | 17:02 | |
| *** rohitksingh has joined #timvideos | 17:36 | |
| *** m4ssi has quit IRC | 18:21 | |
| *** rohitksingh has quit IRC | 19:30 | |
| *** bewbs has quit IRC | 20:50 | |
| *** Kripton has quit IRC | 21:21 | |
| *** Kripton has joined #timvideos | 21:22 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!