Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task 16 backend #52

Open
wants to merge 6 commits into
base: devel
Choose a base branch
from

Conversation

danielolssonIT
Copy link
Contributor

@danielolssonIT danielolssonIT commented Nov 25, 2021

Implementation of Task 16 ArduinoGraphics library support in libSMCE by Group 1 (Daniel and Erik).

Task description: Add to libSMCE the ability to draw on an output screenbuffer, and add to the frontend a display screen component.

Our approach was to create a FrameBufferAccess class to be used in sketches in Arduinoland to access the backend framebuffer.

This branch is currently not working on Windows, as it is branched off from the master branch where the boost libraries seem to fail on Windows. If you want to try out a prototype that works on Windows, try the danielolssonIT:task-16-fix branch.

@codecov
Copy link

codecov bot commented Nov 25, 2021

Codecov Report

Merging #52 (d2d007d) into devel (68c4eb1) will decrease coverage by 2.98%.
The diff coverage is 1.23%.

Impacted file tree graph

@@            Coverage Diff             @@
##            devel      #52      +/-   ##
==========================================
- Coverage   64.95%   61.97%   -2.99%     
==========================================
  Files          81       82       +1     
  Lines        2968     3048      +80     
==========================================
- Hits         1928     1889      -39     
- Misses       1040     1159     +119     
Impacted Files Coverage Δ
include/Ardrivo/WString.h 100.00% <ø> (ø)
src/Ardrivo/FrameBufferAccess.cpp 0.00% <0.00%> (ø)
CMakeLists.txt 94.21% <100.00%> (ø)
CMake/BuildProfiles/UbuntuFocal.cmake 0.00% <0.00%> (-100.00%) ⬇️
CMake/BuildProfiles/DebianBuster.cmake 0.00% <0.00%> (-100.00%) ⬇️
CMake/BuildProfiles/UbuntuGroovy.cmake 0.00% <0.00%> (-100.00%) ⬇️
CMake/Modules/SetupBoost.cmake 75.49% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 68c4eb1...d2d007d. Read the comment docs.

Copy link
Contributor

@RuthgerD RuthgerD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems ok overall, just a couple of small things

Comment on lines +1 to +3
//
// Created by danie on 2021-11-02.
//
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing copyright

Comment on lines +184 to +186
String& operator+=(const String& rhs) {
concat(rhs);
return (*this);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't this be templated much like the concat function?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I second that

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And why do all these return statements have their expression parenthesized?

Comment on lines +1 to +3
//
// Created by danie on 2021-11-02.
//
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing copyright

#include <climits>
#include <iostream>
#include <SMCE/BoardView.hpp>
#include "../../include/Ardrivo/FrameBufferAccess.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shoudn't use relative paths

m_format = format;
break;
default:
return error("Unknown format");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe be a bit more descriptive so that we know where this comes from

extern void maybe_init();
} // namespace smce

int FramebufferAccess::begin(std::uint16_t width, std::uint16_t height, SMCE_Pixel_Format format, std::uint8_t fps) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shoudn't this also take they fb key? (even if its just 0 for now)

m_begun = false;
}

bool FramebufferAccess::read(void* buffer) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uint8_t* instead of void*

return true;
}

bool FramebufferAccess::write(void* buffer) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const uint8_t*

Comment on lines +109 to +114
int FramebufferAccess::bitsPerPixel() const {
if (!m_begun) {
std::cerr << "FramebufferAccess::bitsPerPixel: device inactive" << std::endl;
return 0;
}
return bits_bytes_pixel_formats[m_format].first;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shoudn't this be something on BoardView::Framebuffer itself? seems awfully useful thing to have and weird for it to be present in Ardrivo only

Copy link
Member

@AeroStun AeroStun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Obvious copy/paste of the worst code you could find in the whole project. If I was a code duplicate detection tool I'd scream to be heard from the edge of the galaxy

Comment on lines +10 to +35
enum SMCE_Pixel_Format
{
RGB888, // RRRRRRRRGGGGGGGGBBBBBBBB // SMCE extension
RGB444, // GGGGBBBB----RRRR
};

class SMCE__DLL_RT_API FramebufferAccess {
private:
std::size_t m_key = 0;
SMCE_Pixel_Format m_format = RGB888;
bool m_begun = false;

public:
int begin(std::uint16_t width, std::uint16_t height, SMCE_Pixel_Format format, std::uint8_t fps);
void end();
bool read(void* buffer);
bool write(void* buffer);

[[nodiscard]] int width() const;
[[nodiscard]] int height() const;
[[nodiscard]] int bitsPerPixel() const;
[[nodiscard]] int bytesPerPixel() const;

void horizontalFlip(bool flipped);
void verticalFlip(bool flipped);
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a terrible API
I can see that you copied it from the OV767X header, which is also a terrible API which I cannot alter for compatibility with third-party software.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep in mind that this is an internal header, meant for library patches to use. It is NOT for Arduino user code, and thus NEEDS to provide an equivalent of the FrameBuffer interface, not the shitty OV767X one

Comment on lines +184 to +186
String& operator+=(const String& rhs) {
concat(rhs);
return (*this);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I second that

Comment on lines +184 to +186
String& operator+=(const String& rhs) {
concat(rhs);
return (*this);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And why do all these return statements have their expression parenthesized?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants